FrontierStack in Agentic Workflows

Chapter 13 covered the AI Administrator inside FrontierStack. This chapter covers the other direction: placing FrontierStack inside an agentic workflow you already use. Hermes Bots, Codex, Claude Code, Cursor, Gemini CLI, Grok-powered coordinators and other MCP clients can investigate your real fleet and request work through FrontierStack, while the credentials and final authority remain on the Mac.

14.1The role FrontierStack plays

An agentic system normally has a coordinator that decides what should happen and a set of specialists that know how to do particular work. FrontierStack fills one stable specialist role: Server Administrator. It is also the authority boundary between probabilistic model output and production infrastructure.

The distinction matters. A coding agent may understand a deployment and propose a restart, but it should not carry the SSH key that makes the restart possible. A manager agent may assign an incident, but its message is not authorization. FrontierStack accepts the request, authenticates the caller, narrows the tool set, applies local policy, resolves credentials at execution time, asks a person when required, acts, verifies the observed result and records who requested it.

14.2One request, end to end

1. The coordinator describes a bounded job. For example: “investigate certificate failures on web-02” or “restart the queue worker if it is stopped”.
2. FrontierStack authenticates the caller. A local client uses the owner-only Keychain bridge. A network caller must use the explicitly enabled, paired, signed and scoped path.
3. Tool discovery is filtered twice. frontierstack_find_tools finds tools relevant to the assignment, then the caller’s current scope removes anything it may not use.
4. Policy is applied at execution. Read-only defaults, App Lock, destructive-data restrictions and approval cards are checked again when the chosen tool is called. Discovery never grants permission.
5. Credentials are resolved locally. SSH keys, sudo passwords, database credentials, router logins and cloud tokens stay in the Keychain or linked vault. The model receives neither the value nor a reusable credential-bearing command.
6. The target performs a bounded operation. FrontierStack acts on this Mac or the selected Linux, Windows or Mac host through its reviewed local, SSH or helper path.
7. Completion is verified. A successful process exit is not enough for important changes. FrontierStack checks the app-observed postcondition, writes the audit event and returns an attributable result or durable receipt.

14.3Choose an agentic workflow pattern

The usual starting point is interactive MCP from a coding agent. Add durable tasks, events or mobile supervision only where the workflow needs them.

Integration surfaces

Keep the tool list small

Do not load FrontierStack’s complete tool catalog into every model conversation. Some AI harnesses impose a 128-tool ceiling, and a long irrelevant catalog also makes tool choice less reliable. FrontierStack’s default catalog therefore exposes a small bootstrap pair: frontierstack_find_tools finds only the tools relevant to the current task and caller, and frontierstack_call invokes the selected tool. Use frontierstack tools --full only for inspection or a client that explicitly needs the complete permitted catalog.

Install a credential-free setup kit

In the MCP pane, export an Ecosystem Setup Kit, or read frontierstack://ecosystem-kits over MCP / run frontierstack ecosystem-kits. The generated recipes cover OpenClaw/Hermes-style specialists, Buzz or other human/agent teams, OpenAI-style managers and handoffs, Microsoft workflows, LangGraph, CI/CD, Slack/Teams approval handoffs and a generic future adapter. A kit contains role and endpoint metadata, instructions and safe placeholders — never a password, private key, bearer token or API key.

1. Choose the recipe closest to the coordinator you use and give FrontierStack the Server Administrator role.
2. Connect through localhost, or through FrontierStack’s paired HTTPS path when the coordinator is on another approved device. Do not publish the local MCP port directly.
3. Start read-only. Test discovery, fleet health and help/manual search before enabling any changes.
4. When a change is needed, approve the exact action in FrontierStack. A message in a group chat, an agent card, a prompt or a claimed approval is not authorization.
5. Use the task view to follow progress, cancel work and retain the final verification receipt.

The trust boundary does not move

• Credentials remain local. Server passwords, SSH keys, AI keys and vault values are resolved at execution time and are not exported to the coordinator, setup kit, remote helper, callback or model prompt.
• Discovery is not permission. A role profile, Skill, event, chat identity or tool description says what FrontierStack may be able to do; it cannot enable a tool or widen a caller’s scope.
• Changes pass one gate. MCP, A2A, the CLI and events all use the same App Lock, per-caller scope, destructive-data guardrails, local approval and audit trail.
• Remote helpers stay constrained. The monitor/helper on a server is FrontierStack’s deterministic hands and eyes. It does not host a model, store AI-provider credentials or accept arbitrary MCP work from the network.
• Completion means verified. Durable mutating tasks finish only after FrontierStack records an app-observed postcondition, not merely because a command returned zero.

Observe agents without exposing their work

The Mac’s Agent Operations view is the operational console for worker-host reachability, detected runtimes, active jobs and durable terminal sessions. The iPhone and iPad companion’s Agent Activity view presents a deliberately smaller status surface from the paired Mac. It can show which workers are reachable and which jobs or sessions are active, but it does not send prompts, transcripts, command lines, environment variables, terminal contents or credentials to the phone.

For long-running work on Linux and other fleet hosts, Servers › Host › Terminal Sessions inventories tmux, GNU screen and Zellij sessions. A phone with the required scope can open a direct SSH terminal and attach to a selected session; ending one is a separately confirmed full-control action.

14.4Enabling the MCP server

FrontierStack can discover the common AI clients installed on the Mac and configure its own MCP entry without exposing a reusable credential:

1. Open the MCP Server pane and turn on the server. A fresh setup binds to localhost.
2. Review Detected AI clients. FrontierStack recognizes Amp, DeepSeek Harness Alpha, Hermes Bot Mode, Grok, Codex CLI, Cursor, Gemini CLI, Claude Code and Claude Desktop. Use Set Up Detected, or configure one client from its individual control.
3. Amp setup runs amp mcp add and adds only FrontierStack's owner-only local bridge. It does not enable Amp remote thread creation, start a runner or expose a remote-control terminal.
4. DeepSeek Harness (Alpha) uses a configuration-only plugin bundle for the Harness web profile. It activates Harness's own MCP client and points it at FrontierStack's owner-only bridge. The bundle contains no bearer token, server credential, DeepSeek key or network endpoint. Because DeepSeek Harness is still a developer preview, FrontierStack does not install or repair this Alpha plugin at launch; choose Add Alpha Plugin explicitly and update it with FrontierStack when the supported Harness release changes.
5. Hermes stores each Bot as an isolated profile. Automatic setup repairs only Hermes’ main profile; Set Up Bots is a separate, explicit opt-in for the existing roster. Hermes records the bridge as untrusted, and FrontierStack still applies its read-only default, change and script switches, App Lock, approval and audit rules.
6. Enable Set up detected AI clients at launch if FrontierStack should repair only its own frontierstack entry whenever a stable detected client changes. Other MCP entries are preserved, and Alpha integrations are skipped.
7. The generated entry launches FrontierStack’s owner-only bridge. The bridge retrieves the MCP credential from Keychain when it starts; the bearer token is not serialized into the client’s configuration.
8. For another stdio MCP client, install the FrontierStack CLI and use the command returned by frontierstack mcp.
9. Start read-only. Run frontierstack discover, list fleet health and try a help search before allowing changes or scripts.

14.9.1Grok Bot

Choose Add to Grok to add FrontierStack’s owner-only bridge to ~/.grok/config.toml, or export the project kit when one repository should carry its own Grok instructions. The bridge reads the MCP credential from Keychain at runtime; the TOML file contains no bearer token. Keep a local Grok workflow read-only until its health and help calls behave as expected. A cloud Grok Bot cannot reach the loopback listener. Remote use requires the TLS-protected network path, a paired caller identity and an explicit scope. Never solve discovery by copying the bearer token into bot memory or a project file.

14.9.2SlackBot, Slack handoffs and Buzz

Slack support has three separate parts. The Messaging Gateway sends alerts through a Slack incoming webhook. The ecosystem kit describes a Slack or Teams handoff for an existing bot workflow. Full Fleet also includes the Slack Server Admin Agent Beta, which lets FrontierStack itself join the workspace as a server-administrator teammate.

In Messaging Gateways, copy the supplied private Slack app setup, install it to the workspace, and save the xapp- Socket Mode token and xoxb- bot token in Keychain. No public inbound endpoint is opened. Mention @FrontierStack in an invited internal channel or message the app directly. Replies stay in the Slack thread, carry bounded thread context, and can use the AI Harness with FrontierStack's server, service, network, monitoring, and installation tools.

FrontierStack verifies that the requester is a full member of the connected workspace and refuses guests and Slack Connect conversations. An optional channel-ID list narrows the scope further. Read-only investigation is the default. If an owner enables change requests, the model can select only typed FrontierStack actions; credentials, arbitrary shell, recovery secrets, and self-administration remain unavailable. Every change still passes the Full Fleet gate, App Lock, External changes policy, local approval, audit, task receipt, and outcome verification. A Slack message, reaction, role claim, or button is never approval.

Buzz is a service integration and a team-recipe target. FrontierStack can install or connect the hosted or self-hosted Buzz stack and monitor its relay and dependencies. The exported Buzz-style kit describes scoped human and agent roles and selects an existing MCP, A2A, CloudEvents or CLI route. It is not a live Buzz agent endpoint, and it contains no Nostr key, server credential or FrontierStack bearer token.

The installed frontierstack CLI also uses stateless MCP by default. Run frontierstack discover for machine-readable protocol and capability information; frontierstack info reports both the preferred stateless revision and the supported legacy revisions.

An unfamiliar client can read the frontierstack://manual resource or call search_app_help to learn app-authored procedures without exposing arbitrary files.

The separate MCP Servers pane can manage other servers in either generation. Its Automatic setting tries server/discover first and falls back to legacy initialize only when necessary. A green Stateless mark appears in the server list only after the HTTP server proves support; a stateless stdio server can be marked explicitly because the external client owns that process and handshake.

For example, the AppSignal preset connects to AppSignal’s hosted MCP endpoint through a reviewed, version-pinned mcp-remote bridge. The bridge performs AppSignal’s browser OAuth flow, so no AppSignal token is placed in the preset, client configuration or process arguments. This agent connection is separate from FrontierStack’s deterministic AppSignal health monitor: use the personal API token and app ID in the AppSignal service pane for Local Health and alerts, and use OAuth MCP only when an agent needs a deeper investigation. Start with read-only AppSignal access and review any write-capable tool before delegation.

14.5Signed requests and device pairing (FS1)

The control and MCP servers add a per-device signed-request layer — FS1 — on top of the bearer token and TLS. Each paired device holds its own Ed25519 private key and signs every request; FrontierStack verifies the signature against the device you approved, so a leaked token alone cannot drive anything.

• Per-device scopes. Each device is granted a scope from read-only up to full control, set on the Mac.
• One-tap revoke. Remove a device and it is cut off instantly, without affecting the others.
• This is the same mechanism the iPhone and iPad app uses to pair — see the Mobile Manual, and the trust model in Chapter 10.

14.6External AI jobs

Beyond live MCP, FrontierStack can hand a job to a subscription AI CLI — package up a task and let your local Claude (or similar) work it under your plan, then bring the result back into the app. This is how heavier, longer-running analysis runs without a metered API bill, and it pairs with the Data Map (a per-location data-flow diagram) so the agent has the context it needs. External AI jobs are managed from the AI stack (Chapter 15).

14.7Skills, notes, memory and Obsidian over MCP

An external harness reaches the same knowledge surfaces as the built-in Administrator, subject to the same gates:

• Skills — your curated playbooks are discoverable and loadable on demand.
• Shared notes — only notes you unlocked with “Share with AI” are readable.
• Long-term memory — the same memory.md of preferences and standing rules.
• Obsidian — if you have linked an Obsidian vault, the agent can search your SOPs and runbooks and follow the documented procedure (Chapter 12).

14.8The Fleet Skill — portable context for any agent

The MCP server lets an agent act on your fleet. The Fleet Skill is the other half: static context that teaches an agent your world before it touches anything. The Fleet Skill pane generates a SKILL.md — your servers and their roles, OS, services and how to reach them; your network locations; your KVMs and power sources; and a free-text block of your own rules and preferences — with every secret stripped out. An agent that reads it picks the right host, uses the right path, and respects your conventions instead of guessing.

It is written to ~/.claude/skills/fleet/SKILL.md, which Claude Code discovers automatically — the description: in its frontmatter tells the model when the skill is relevant. MCP-connected agents can pull the same content through the get_fleet_context tool, and you can optionally also emit ~/AGENTS.md for CLIs that read that convention. Turn on auto-update and the skill is rewritten a few seconds after your fleet, locations or KVMs change, so it never drifts from reality.

Think of it as the difference between a map and a remote control. The MCP is the remote control — live, authenticated, able to do things. The skill is the map — zero-setup, portable, safe to hand to any agent, and the thing that stops a capable tool from doing the wrong thing in the right way.

14.9When to use which

All three reach the same guarded tools and the same live app state. Pick by where you prefer to work; the safety guarantees do not change.