Agent-native

Capxul is built on an assumption about where software is going: over time, more application-building and more workflow execution is handled by agents. A financial platform has to decide what that means for it. Capxul's answer:

Agent-native means an agent can directly do what a user or a developer can do — in a simple, controlled way — through SDKs, tools, and delegated permissions.

Not a chatbot bolted onto a product. Not one blessed "agent UX". The platform exposes safe, structured primitives, and different products, agents, and interfaces compose them.

The same properties serve humans and agents

Nothing about the SDK was forked to make it agent-usable — the design choices that make it safe for a developer are the ones that make it legible to an agent:

• Method-based intent. client.payments.pay(...), client.org(orgId).invite(...) — an agent expresses what should happen in domain verbs, not by assembling low-level operations.
• An explicit result boundary. Every method returns Promise<CapxulResult<T>> — ok or a typed CapxulError, never an unknown thrown value. An agent can branch on failure as reliably as a program.
• Typed recipients, opaque ids. There is no API shape where an agent can fat-finger a raw address; recipients are typed references and accounts are opaque ids.
• Guardrails in the platform, not the prompt. The instant-send guardrail means an agent cannot send irreversibly to an unvalidated recipient — the worst case of a confused agent is a recoverable, cancellable Commitment. Safety rules enforced below the tool layer do not depend on the agent behaving.

This is the trade-off agent-native implies: controlled primitives are narrower than raw access, for agents exactly as for developers. That narrowness is the feature.

Three levels of agent participation

Agent-native applies at more than one altitude:

1. Agents building. A developer hands the SDK and these docs to a coding agent and has it build Capxul-powered features. The docs are written to be sufficient grounding for that (see below), and the published packages are the same ones humans use.
2. Users delegating. A Capxul user grants an agent specific, scoped permission to act — pay people, run payroll, send payment requests, pull up payment state — without handing over their identity wholesale. Today the concrete shape of this is the MCP server's session model; richer delegation is platform direction, not yet a published contract (see Capability status).
3. Agent apps embedding. An agent application embeds Capxul's financial primitives inside its own product — organizations, payments, payroll as capabilities of the agent's product, the way apps embed auth or payments widgets today.

The MCP server

For agents that speak tools rather than TypeScript, @capxul/mcp is a runnable Model Context Protocol server — npx @capxul/mcp serve — exposing financial operations as MCP tools over Streamable HTTP. An agent authenticates a user through an email OTP tool pair and receives an opaque session token bound to that MCP session; from there, tools cover account readiness, Money balances, and sending a sponsored payment, with a liveness probe that needs no secrets and OAuth bearer gating for deployments that require it.

The MCP tool set is deliberately narrower than the SDK today — a starting surface, not a mirror of every client method. Details and setup live in the agent surface docs.

These docs are part of the surface

If agents build from docs, docs are infrastructure. This site treats machine readers as first-class:

• llms.txt — an index of the whole site for machine readers.
• llms-full.txt — the entire docs content in one file, for tools that want everything in context at once.
• Per-page markdown — every page is also published as a static markdown file (this one: /llms.mdx/docs/concepts/agent-native/content.md); see machine-readable docs.
• Copy Markdown — every page has a copy-as-markdown button for pasting into an agent's context.

The writing conventions here — grounded facts, one honest capability map, stable vocabulary — exist for the same reason. An agent cannot ask a hallway question when a page oversells; docs that are safe to build from unsupervised are the bar.

The bigger picture

The through-line of this whole concepts section is that Capxul's surface is made of stable, structured, guardrailed primitives instead of ambient access. Agent-native is what that design buys at the platform level: the same primitive is a hook for your frontend, a method for your server, and a tool for your agent — and the platform's safety rules hold across all three, because they live below the surface rather than in any one consumer.