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. The server is on by default and binds to localhost; you can turn it off there.
2. Review Detected AI clients. FrontierStack recognizes Amp, DeepSeek Harness Alpha, Hermes Bot Mode, Grok, Codex CLI, Cursor, Gemini CLI, Claude Code, Claude Desktop and Xcode (26.3 and later). 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.12.1Xcode

Xcode 26.3 and later (including Xcode 27 on macOS 27) hosts coding agents and speaks MCP in both directions. Add to Xcode writes FrontierStack’s owner-only bridge into ~/Library/Developer/Xcode/CodingAssistant/mcp-servers.json, the list of MCP servers the Claude, Codex and Gemini agents inside Xcode may use. An agent working on your app can then ask FrontierStack about the server, database or site it is targeting, and request bounded work under the same read-only default, change switch, approval and audit rules as any other client.

In the other direction, the AI Administrator’s xcode tool talks to Xcode’s own MCP server through xcrun mcpbridge: list schemes and targets, build, run all or some tests, read the build log, render a SwiftUI preview, search or edit project files, create a project from a template and drive a simulator. Turn on Xcode › Settings › Intelligence › Model Context Protocol › Allow external agents to use Xcode tools and keep the project open; Xcode shows an alert when FrontierStack connects. Xcode’s read-only tools run freely, while builds, test runs, edits and scheme switches require Allow changes. For a project that is not open in Xcode the tool runs xcodebuild in the in-app console instead. Do not run both against the same project at once: two builders can corrupt Xcode’s build database. The pane also shows the claude mcp add … xcode -- xcrun mcpbridge command that gives Claude Code the same Xcode tools.

14.12.2Grok 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.12.3SlackBot, 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.5Setting up FrontierStack for agent platforms

An agent platform can use FrontierStack in one of three ways. A coding agent calls it as an MCP tool server, as described in the previous section. An orchestrator can employ it as a worker that takes assignments: a Paperclip heartbeat or an A2A task. And any agent that has a shell can drive the frontierstack CLI. Whichever route you pick, FrontierStack plays the same Server Administrator role, and the same App Lock, read-only default, approvals and audit log apply.

14.12.4Paperclip: hire FrontierStack as the company’s system engineer

Paperclip runs a team of agents as a company, with an org chart, budgets, goals and approvals. FrontierStack can join that company as its system engineer and network administrator. It takes the infrastructure issues assigned to it, investigates them with its own tools and reports back on the issue.

1. Install Paperclip on this Mac, as your own user: npx paperclipai onboard --yes. Heartbeats run FrontierStack locally, so Paperclip can’t live on another machine.
2. Open the Paperclip pane in the Agent Operations section. Under Connection, check the endpoint (http://127.0.0.1:3100 by default). If Paperclip runs in authenticated mode, paste a board API key as the token.
3. Under Work as a Paperclip agent, turn on Accept Paperclip heartbeats and click Install heartbeat command. This writes ~/.frontierstack/bin/frontierstack-paperclip.
4. Open Hire FrontierStack into a company, click Load companies, choose the company and click Hire as DevOps agent. This creates an agent titled “System Engineer & Network Administrator” that uses the process adapter. You can instead click Copy adapter config and paste it into an agent you create in Paperclip yourself.
5. Assign it an issue in Paperclip, for example “find out why mail from web-02 is bouncing”. Its progress appears in Paperclip’s run transcript.

On each heartbeat, Paperclip runs the heartbeat command with a short-lived run token. If FrontierStack isn’t running, the command starts it hidden in the background (a cold start can take up to two minutes). FrontierStack then checks out the assigned issue, investigates, comments and sets the issue to done, blocked or in review. If another agent already has the issue checked out, FrontierStack leaves it alone. The run token is sent only to the Paperclip server set in the pane.

Let Paperclip request changes is off at first, so the agent only investigates and recommends. When you turn it on, each typed change still follows App Lock and your External changes setting: it runs, waits in the pane with Approve once, Allow for 5 minutes and Deny, or is refused.

14.12.5A2A supervisors and manager agents

A coordinator that speaks A2A 1.0, such as an OpenClaw or Hermes supervisor or a LangGraph manager, can hand FrontierStack a durable task instead of calling tools one at a time. In the MCP Server pane, turn on Accept delegated A2A tasks (off by default). An agent on this Mac connects over localhost. An approved remote coordinator uses the paired, certificate-pinned HTTPS route. The Agent Card only describes FrontierStack; it grants nothing. A natural-language assignment is always read-only. A change must be sent as a typed FrontierStack request, and it then passes the usual scope, App Lock, approval, audit and verification checks. Progress streams over SSE, and optional callbacks must go to public HTTPS addresses. Export the matching Ecosystem Setup Kit for a ready-made, credential-free recipe.

14.12.6Agents with a shell, CI and scripts

Install the CLI from the MCP Server pane or Remote Control & Lock ▸ Command Line. An agent can then run frontierstack discover to see what’s available, frontierstack role to read the Server Administrator profile, and frontierstack call <tool> '<json>' to run a tool. Give it credentials with frontierstack run (see Credentials for agents), never by pasting them into the prompt. If the platform works on a schedule or at night, turn on the background service so read-only checks work with the app closed (Working with the app closed).

14.12.7Before a platform makes changes

• Connect it read-only first. Check discovery, fleet health and a help search.
• Give Claude Code the Fleet Skill so it knows your servers before it connects, and turn on auto-update so the skill follows fleet changes.
• Turn on changes per platform: the MCP change switch, Let Paperclip request changes, or typed A2A requests. Keep approvals on the Mac or the paired iPhone.
• Watch the work in Agent Operations ▸ Activity and the audit log. The iPhone’s Agent Activity view shows status without copying prompts or transcripts.

14.6Signed 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.7External 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.8Skills, 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.9The 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.10Credentials for agents, without a .env

Agents often need an API key or a password to run a command. Don't paste it into the chat, and don't keep it in the repo. Put it in Script Secrets (AI Administrator ▸ Script secrets bar), turn on Let frontierstack run use these secrets, and let the agent run:

frontierstack run --secret CLOUDFLARE_API_TOKEN -- terraform apply

The value is set as an environment variable for that one command and masked in its output, so the agent sees the command work without reading the value. A project can instead commit a .env.frontierstack of names only (DB_PASSWORD=fs://DB_PASSWORD); frontierstack run -- <command> in that folder fills it in. The agent guide, the exported skill and the Fleet Skill all tell agents to work this way. Already keep credentials in a repo? Import from a Repo… moves them in (Ch 13).

14.11Working with the app closed

FrontierStack does not have to stay open for agents to use it. Keep MCP and the CLI available when FrontierStack is closed is on by default (MCP Server pane, or Remote Control & Lock ▸ Command Line). A small background service then starts when you log in and owns the local MCP and CLI ports (8788 and 8799 by default). With the app closed, it answers discovery and a set of read-only checks itself: WHOIS, IP analysis, certificate expiry, port checks, the open-relay test, disk usage, top processes, a metrics snapshot, reading hosts files and remote files, and MySQL/PostgreSQL table checks, on this Mac or on your saved servers. For anything else it starts FrontierStack hidden and passes the request on. While the app runs, every request goes straight to it, so App Lock, approvals and the audit log behave exactly as before.

Check what is answering with frontierstack info ("answering": "app", "core" or "none") and frontierstack headless status. The service starts at login, not at boot. Turn on Automatic login in Headless Mac Setup if MCP should come back by itself after a restart or power cut. After an app update the service restarts itself on the new version once open requests are done. Paired iPhones and iPads keep reaching the Mac through the service, with no re-pairing: from the phone's dashboard, Start FrontierStack on the Mac starts it hidden and Open FrontierStack on the Mac opens its window. Alert pushes to the phone keep arriving while the app is closed.

14.12When 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.