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. 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 Grok, Codex CLI, Cursor, Gemini CLI, Claude Code and Claude Desktop. Use Set Up Detected, or configure one client from its individual control. Claude Code shows the exact claude mcp add command; the other supported clients have an Add to… action.
3. Enable Set up detected AI clients at launch if FrontierStack should repair only its own frontierstack entry whenever a detected client changes. Other MCP entries are preserved.
4. 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.
5. For another stdio MCP client, install the FrontierStack CLI and use the command returned by frontierstack mcp.
6. Start read-only. Run frontierstack discover, list fleet health and try a help search before allowing changes or scripts.

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.

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.

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.