The flagship idea

Capabilities an agent doesn't have to have.

Most agent platforms assume every capability must be implemented before an agent can use it. GoTo Agents separates the two with a pair of ideas that compose: MCP Exposures — capabilities as declarations — and Agent-Initiated Requests (AIR) — agents that ask the calling side for what they can't do themselves.

Exposures: a capability is a declaration first

In GoTo Agents, registering an MCP capability doesn't require a running server. An exposure declares a capability surface — what tools exist, what they're for — and separately says how (or whether) it's implemented:

  • Connected server — the normal case: the exposure points at a live MCP server (local command or URL) and calls execute there.
  • Proxy exposure (exposure_mode: proxy) — the tools are declared inline and no server is ever contacted. Every call routes back to whoever is talking to the agent, as an Agent-Initiated Request.
  • Capability stub — the purest form: an interface declaration with no implementation at all. The capability exists in the agent's world — it can plan around it, attempt to use it — before anyone has built it.

The same capability can be locally executed in one workspace and client-routed in another. Routing is a configuration decision on the declaration — never hardcoded into agent logic.

AIR: the agent asks, the caller answers

When an agent needs something it can't execute — a web search it doesn't have, a judgment call only you can make, a file only the connected client can reach — it doesn't fail and it doesn't pretend. It expresses the need as a structured request in its response, and the other side fulfils it however they see fit.

Two routings, one pattern:

  • HITL (human-in-the-loop) — the request surfaces to you in the web UI or a notebook: an approval, a preference, a thing only you know.
  • CITL (client-in-the-loop) — the request routes to a connected LLM client — say, a Claude Code session driving GoTo Agents over MCP — which fulfils it with its capabilities and returns the result.

Crucially, this is not RPC. It's a conversational exchange: the other side may fulfil the request, ask for clarification, answer partially, or decline — and the agent adapts to whatever comes back. That's what makes it robust where rigid tool contracts are brittle, and it's the same philosophy as the rest of the product: the human (or the caller) stays a first-class participant, not an execution backend.

What it unlocks

  • Prototype capabilities before building them. Declare a stub, run real sessions, and play the capability's part yourself through conversation. When the shape is right, implement it — the declaration doesn't change.
  • Human-only capabilities, formally. Approvals, taste, subjective judgment, access only a person has — declared like any other capability, fulfilled by a person, forever.
  • Borrow the caller's powers. A Claude Code session that drives GoTo Agents can also lend its web access, local filesystem, and credentials to GTA agents — GoTo Agents implements none of it.
  • Mock and test cheaply. Client-route a capability in a test workspace and script the responses; flip the same declaration to a live server in production.

Where it lives

  • core/mcp_manager.py — exposure declarations: exposure_mode, proxy detection, stub detection, config normalization.
  • core/air_emission.py — how an agent's request is structured and emitted.
  • core/mcp_tool_adapter.py — how exposed tools surface to the agent runtime.
  • roadmap_docs/agent-initiated-requests.md — the design document, including requirements and terminology.

Status: functioning in the developer preview and actively evolving — the design document is the source of truth for where it's headed.