DEV Community: fcn06

What If the Enterprise API of the Future Is an Agent?

fcn06 — Mon, 31 Aug 2026 03:30:52 +0000

We have been experimenting for some time with an architecture for secure AI agents, enterprise systems, messaging, identity, and controlled execution. This is an early, ongoing experiment, not a finished product — treat everything below, including the parts we've prototyped, accordingly. While working on it, we arrived at a thesis worth putting in front of people who think about integration and agent security for a living:

APIs don't disappear. The enterprise boundary moves upward — from predefined technical interfaces toward negotiated, policy-constrained interaction contracts — with APIs and tools remaining the deterministic execution substrate underneath.

The goal isn't to replace APIs with LLMs. It's to reduce how much cross-enterprise integration logic must be agreed in advance, replacing some of it with governed runtime negotiation where that's safe. We currently call the software actor that carries out this negotiation on an enterprise's behalf a B2B agent.

The current model

Today, enterprise integration usually looks like this: Company A writes an integration against Company B's API, which talks to Company B's business systems. Simple in shape, expensive in practice — Company B has to define REST endpoints, schemas, authentication, scopes, versioning, error models, webhooks, and SDKs, and Company A has to understand all of it before a single request can succeed.

This works. But it also creates an enormous amount of integration work. Every company exposes slightly different models. Every pair of systems requires mapping. And even when two companies use the same protocol, they rarely use the same business semantics.

Agents change something important — but not the part people assume

Agents are different from traditional applications because they can reason about intent. Instead of saying:

POST /api/v3/orders

an agent can say:

I want to order 500 units of product X, delivered in the EU before Friday. The maximum total price is €20,000.

It's tempting to conclude that agents therefore replace APIs. We don't think that's quite right, and we don't think it's even the interesting claim. The API layer — createOrder, reserveInventory, approvePayment, cancelShipment — still needs to exist somewhere, deterministic and auditable, because that's what actually moves goods and money.

What agents can plausibly remove is a precondition: today, Company A has to understand Company B's native interface before anything can happen. If agents can negotiate a shared, machine-readable description of the relationship at runtime, that precondition gets weaker. The API doesn't disappear — it moves one layer down, behind a negotiation and authorization layer:

A possible future interaction

Imagine Company A's agent discovering Company B's B2B agent and saying:

I need access to quoting, ordering, order status, and cancellation.

Company B's agent answers:

I support those capabilities. Orders may be cancelled until dispatch. Transactions above €10,000 require additional authorization. I only support EUR settlement for this relationship.

The two agents don't necessarily need identical native APIs. Instead, they negotiate an Interaction Contract — a machine-readable definition of the relationship. A minimal illustration:

purpose:
  supplier_order_management

capabilities:
  - quote
  - create_order
  - order_status
  - cancel_order

constraints:
  max_order_value:
    currency: EUR
    amount: 10000

geography:
  - EU

cancellation:
  allowed_until: dispatch

validity:
  expires_in: 30_days

A skeptical reader might reasonably ask: isn't this just OAuth scopes plus a JSON Schema plus a policy engine? Fair question. What we think makes an Interaction Contract a distinct artifact, rather than a fancy permission set, is that it's meant to bind several dimensions together at once — counterparties and identity requirements, permitted business purposes, capabilities, agreed semantics, constraints, data policy, required workflow ordering, delegation rights, obligations (SLAs, confirmations), validity, revocation, and attestation — as one versioned, signed, hashable object. That's closer to a machine-enforceable operational relationship than a scope list.

One clarification worth stating plainly: "Interaction Contract" here means a machine-enforceable technical agreement between two software actors, not a legally binding commercial contract — although the two concepts may eventually need to intersect, particularly once commercial terms are involved.

We're also not fully settled on whether an Interaction Contract is best modeled as one object or as an envelope over several independently versioned artifacts — identity assertions, capability agreement, semantic mapping, policy constraints, delegation constraints, obligations, and attestations. The semantic mapping, for instance, may need to change on its own timeline while the rest of the relationship stays fixed. We don't think this needs to be resolved for the argument to hold, but it's likely to matter once this moves past a prototype.

Where this sits relative to MCP and A2A

Anyone following this space will reasonably ask whether this is just reinventing A2A. It isn't, and we want to be explicit about why, because we'd rather be complementary to existing protocols than start a standards fight we don't need:

At its core, MCP standardizes agent/tool and resource interaction.
A2A provides agent ↔ agent interoperability — discovery, capabilities, task exchange between agents.
Interaction Contract governs the enterprise ↔ enterprise relationship those agents are allowed to establish — the negotiated scope, constraints, and semantics.
Trust Gateway is the policy decision and execution-authorization layer sitting behind each side.
ExecutionGrant is the per-operation authority actually handed to an executor.

Put differently: assume A2A solves communication and interoperability between agents. Our question is what governs the relationship the two agents are allowed to establish, and what stops either side from acting outside it.

There are adjacent standards and ideas here that solve important parts of this problem already. OAuth Rich Authorization Requests (RAR) provides a way to express fine-grained, transaction-specific authorization rather than relying only on coarse scopes. AuthZEN standardizes interaction between policy enforcement and policy decision points. MCP addresses tool and resource interoperability, while A2A addresses interoperability between agents.

We're not proposing replacements for those. The hypothesis is about the layer that composes identity, negotiated business semantics, relationship constraints, delegation, and operation-level authorization into a governed cross-enterprise interaction. In that model, existing standards can provide much of the machinery underneath rather than being displaced by it.

Agents propose. Gateway decides. Executors verify.

This is the load-bearing sentence in the whole design, and probably more important than the "B2B agent" framing itself. We don't think two LLMs should negotiate something and then simply execute it — that would be far too dangerous. The architecture deliberately separates reasoning, authority, and execution into different actors:

The agent doesn't hold final execution authority. A separate Trust Gateway control plane evaluates policy and issues short-lived cryptographic execution grants; an executor performs the actual side effect only after verifying that grant.

Here's a property we think deserves a name of its own. Between "what was authorized" and "what actually executes," there's a window where the two can diverge — an authorized transfer(account=A, amount=100) becoming an executed transfer(account=B, amount=10000). It's structurally the same shape as a classic TOCTOU (time-of-check-to-time-of-use) bug, just at the agent-action layer instead of the filesystem layer. In our prototype, execution grants are short-lived and single-purpose, and execution authorization is cryptographically bound to the specific tool and the exact canonical arguments via an input_hash, so a grant is only valid for the precise action it was issued for — not "an action like this one." (Preventing reuse of the same grant across distributed executors is part of the design goal; we're not yet claiming that guarantee is airtight in every deployment topology.) That's one of the security properties we consider important enough not to bury in a longer capability list — alongside delegation, revocation, and distributed policy state, which matter just as much and which we haven't fully covered here.

So the model isn't "agent executes anything." It's: agent proposes intent → Interaction Contract constrains the relationship → Trust Gateway applies deterministic policy → a cryptographically bound ExecutionGrant → executor.

Agents negotiate meaning, not authority

In our hypothesis, the agent negotiates business intent, compatible capabilities, schema mappings, data requirements, transaction constraints, workflow expectations, and delivery semantics. It should never decide whether an enterprise action is authorized — that stays deterministic. More precisely: agents may negotiate the shape of a proposed permission envelope, but they cannot confer authority that the enterprise hasn't independently delegated.

Two agents might negotiate a maximum transaction of €50,000, but if enterprise policy caps it at €10,000, €10,000 should win:

effective authority =
    negotiated contract
    ∩ enterprise policy
    ∩ identity authority
    ∩ delegated authority

A negotiated agreement can only make the permitted space smaller. It should never be able to create new authority — though as we note below, even this formula isn't the whole story once multiple contracts combine.

What we've prototyped so far

This isn't purely theoretical, but it's still early, and only a slice of it is public: a portion of the underlying execution-control-plane concepts is open source; most of the current build is private and iterating quickly. Treat the open-source repository as the visible tip of an experiment still taking shape, not the full system.

Concretely, we've implemented the negotiation lifecycle (discover, propose, counter-propose, accept, attest) as working code, and the authorization path: the Trust Gateway verifies canonical terms hashes, counterparty identity, monetary limits, and geographic constraints, and stamps a contract_id and contract_hash into every execution grant issued under that agreement. That gives a provenance chain from what did these two agents agree to what exact operation actually happened — identity, contract, policy, and input hash all feed into the grant, which feeds into the execution result. This is the target behavior we're validating, not a claim that it's proven at production scale.

The harder problem may be semantic, not cryptographic

OAuth, PKI, signing, and grant verification at least give us mature primitives to work with — that doesn't mean enterprise deployment (key custody, federation, revocation, lifecycle) is easy, just that the building blocks exist. The harder unresolved problem in this architecture is closer to: what does cancel_order mean to Company A versus Company B? "Cancel" for A might mean void the PO outright if unshipped; for B it might mean file a cancellation request subject to supplier approval. Two agents can linguistically convince each other those concepts match without them actually matching — a kind of semantic false agreement that's more dangerous than an outright rejection, because it fails silently.

We suspect the safer pattern is not "the LLM invents a mapping and we trust it," but something closer to: agent proposes a mapping → the mapping is captured as a deterministic, versioned artifact → schema and policy validation → optional human or certification approval → the mapping is hashed and versioned → future executions reference the approved mapping, not a fresh inference. In other words, use AI to generate interoperability artifacts, not to be the interoperability artifact.

Why this could change integration

We've spent enormous effort standardizing application interfaces — REST, OpenAPI, OAuth, and now MCP and A2A. Our hypothesis is that the long-term abstraction sits one layer higher: instead of requiring every company to expose the same business API, we standardize the protocol for discovering capabilities and negotiating interactions, while the API layer keeps doing the deterministic work underneath. We'd still need standards — arguably more than ever, for identity, capability discovery, authorization, delegation, revocation, and audit — just not the same application-level interface from every company.

A brief note on interfaces beyond APIs

The same model may eventually extend to human-facing commerce, where a user's agent negotiates directly with a merchant's agent under delegated authority. That's a separate topic, though, and probably deserves its own article.

There are still many hard questions

This is a work in progress, and the open questions probably outnumber the answers so far:

How much should agents really negotiate? Free-form negotiation is tempting but probably a mistake; negotiation likely needs to happen inside well-defined capability and policy boundaries, not from a blank slate.

Composition and cumulative authority. Authorization can't always be evaluated one action at a time. Individually safe grants can become unsafe together — read access to a catalog, permission to submit a purchasing recommendation, and permission to send an external message might each be fine alone and risky combined. Evaluating contract ∩ policy ∩ identity ∩ delegation may also require transaction history, cumulative spend, velocity limits, and separation of duties — which likely means the Trust Gateway needs stateful authorization, not a static per-request check.

Transaction and failure semantics. Negotiating intent is only part of the problem. An order gets created, inventory reservation fails, payment authorization already succeeded, and the network response never arrives — now what? Cross-enterprise actions still need deterministic treatment of retries, idempotency, partial failure, compensation, reconciliation, and disputed outcomes. Agents don't make any of that go away.

Discovery trust. How does Company A know it discovered the real Company B agent, and not an impersonation? Discovery is only useful if the counterparty's endpoint, organization, capabilities, and credentials can be authenticated and kept current — which points back to identity infrastructure, not just negotiation logic.

How should contracts be signed? DID-based signatures are one option, traditional enterprise PKI another — in many environments, both may need to coexist.

How does human approval fit? Some contracts could be automatic. Others should require approval when a new counterparty is involved, financial limits are high, new data categories are exposed, new jurisdictions are involved, or sensitive capabilities are requested.

Where does payment fit? Once an Interaction Contract includes commercial terms and not just capabilities and permissions, it starts looking like a machine-readable commercial agreement — which is exactly why we're careful to distinguish it from a legal contract above.

Why we think this is worth exploring

We don't know whether this exact architecture will become the future of enterprise integration. But we increasingly believe something structurally similar will emerge. Agents are becoming first-class software actors with identities, delegated authority, and increasingly consequential permissions. They are beginning to discover other agents and capabilities, and are likely to initiate increasingly consequential transactions. Once that happens, enterprises will need a controlled interface between the probabilistic agent world and deterministic business systems.

Agents negotiate. Contracts capture agreement. Gateways authorize. Executors execute.

That's the direction we're experimenting with.

We'd like your feedback

We'd be especially interested in hearing from people working on MCP, A2A, agent identity, API gateways, authorization, payments, B2B integration, autonomous commerce, or zero-trust agent architectures. Three questions we're genuinely unsure about:

The negotiation boundary: which parts of a B2B integration could safely be negotiated at runtime, and which must stay predefined?
The trust boundary: is "agents propose, gateways authorize, executors verify" the right separation of responsibilities — or does it introduce a layer you wouldn't actually want?
The semantic boundary: can business semantics ever be safely negotiated dynamically, or will enterprises always need certified canonical models for anything consequential?

Comments here are the easiest way to reach us. If you spend five minutes poking holes in this, we'll read every one of them.

Stop Giving AI Agents Your Master Password: UCAN Delegation

fcn06 — Sun, 23 Aug 2026 08:02:16 +0000

Why handing a permanent API key to an autonomous AI agent is a bad idea — and a simpler way to grant it just enough trust, for just long enough, using cryptographic "visas" called UCANs.

Status: work in progress. This is an early write-up of something I'm actively building, not a finished product announcement. I'm sharing it specifically to get feedback — on the idea, the explanation, and the approach itself — before taking it further. See the last section for exactly what kind of feedback would help most.

The problem, in one picture

Imagine you hire an intern to add one meeting to your Google Calendar. Would you hand them:

A) Your Google password — which also opens your email, your Drive, and your saved credit cards, or
B) A note that says "You may add one event, today, between 2 and 4 PM. Nothing else."

Everyone picks B for a human intern. Almost nobody picks B for an AI agent.

Today, most AI agent frameworks (LangChain, CrewAI, AutoGen, and friends) are wired up with Option A: a permanent, all-powerful API key pasted straight into the agent's code or environment variables. If that agent gets tricked by a malicious webpage, hallucinates, or simply has a bug, it doesn't just fail — it fails with full permissions. Wiped databases and drained accounts are not hypothetical; they're a Tuesday.

The obvious fix — "just ask the human before every single click" — kills the entire point of having an autonomous agent. Nobody wants to approve every calendar invite by hand.

We wanted a third option: agents that can act on their own, but only within a narrow, time-boxed, cryptographically provable slice of permission. That's what this article walks through.

The idea: give agents a passport, not a master key

Think about how you cross a border. You don't hand a customs officer your entire identity and bank access — you hand them a passport, and inside it, a visa that says exactly which country you can enter, for how long, and for what purpose.

We apply the same idea to AI agents:

A UCAN (User Controlled Authorization Network) is the digital equivalent of a visa: a small, signed piece of proof that says "person X allows agent Y to do Z, until this time."
A Virtual Passport is the little folder an agent carries around, holding all the UCANs (visas) it has been issued by different people or departments.

 ┌──────────────────────────────────────────────────────────┐
 │                AGENT'S VIRTUAL PASSPORT                  │
 │  Agent: "Supervisor Agent #7721"                          │
 │                                                            │
 │  🎫 Visa #1 — issued by Alice                              │
 │     Allowed: create a Google Calendar event                │
 │     Valid for: 10 minutes                                  │
 │                                                            │
 │  🎫 Visa #2 — issued by Finance                            │
 │     Allowed: approve refunds up to $50                     │
 │     Valid for: 1 hour                                      │
 └──────────────────────────────────────────────────────────┘

Each visa is signed with real cryptography (Ed25519 signatures), so nobody can forge one or quietly extend its lifetime. Under the hood, a UCAN is just a small, signed JSON object:

{
  "issuer": "did:twin:alice...",
  "audience": "did:twin:supervisor-agent...",
  "capabilities": [
    { "resource": "google_calendar", "action": "create_event" }
  ],
  "expiry": 1787491200
}

issuer — who is granting the permission (Alice)
audience — who receives it (the agent)
capabilities — exactly what the agent may do, nothing more
expiry — the moment this visa stops working, automatically

No central authority has to revoke anything — the token simply stops being valid. That's the whole trick.

A narrower visa for a narrower job: delegation

Here's the part that makes this genuinely useful for multi-agent systems, not just a single bot: an agent can hand a smaller visa to another agent.

Say Alice asks her "Supervisor" agent to schedule a client meeting. The Supervisor spins up a small "Worker" agent just to touch the calendar. It doesn't hand the Worker its own visa (which might also include refund permissions) — it mints a new, narrower visa, stripped down to exactly calendar: create_event, and nothing else.

This is called attenuation: every time permission is delegated, it can only get narrower, never wider. A worker agent can never end up with more power than its supervisor had. That single rule is what makes it safe to build swarms of agents that spawn other agents without the whole thing turning into a permissions free-for-all.

What actually happens when the agent tries to act

Two things are worth noticing:

The agent never talks to Google Calendar directly with a permanent credential. It shows its visa to a middleman — the Trust Gateway — which checks that everything is legitimate and in-scope, then issues a tiny, single-use pass valid for just 30 seconds.
That 30-second pass is also cryptographically tied to the exact action requested (the specific meeting title and time, hashed). Even if it leaked, it couldn't be replayed or repurposed for a different action.

If an agent ever tries to do something outside what its visa allows — say, a $500 refund when it only has a $50 visa — the request doesn't fail silently or get approved anyway. It gets parked and sent to the human for a real approval (a fingerprint or Face ID tap on their phone), before anything happens.

So the agent gets to act autonomously within its lane, and a human only gets pulled in when something falls outside that lane. That's the balance the "God-mode key vs. approve-everything" dilemma from the start of this article was missing.

Trying it yourself

The gateway that does the checking — the Trust Gateway — is open source and written in Rust. Here's the shortest possible version of the flow above, using its API directly. All three calls below are handled entirely inside the open-source trust_gateway itself — no other service is involved in minting, validating, or checking policy on a token.

Swap in your own gateway's address wherever you see <YOUR-TRUST-GATEWAY-URL> (e.g. http://127.0.0.1:3060 if you're running it locally).

1. Alice mints a visa for her agent, scoped to calendar access only, for one hour:

curl -s -X POST https://<YOUR-TRUST-GATEWAY-URL>/v1/ucan/mint \
  -H "Content-Type: application/json" \
  -d '{
    "issuer": "did:twin:alice...",
    "audience": "did:twin:supervisor-agent...",
    "capabilities": [{ "resource": "google_calendar", "action": "create_event" }],
    "ttl_seconds": 3600,
    "issuer_seed_hex": "<alice_private_seed>"
  }'

This returns a signed UCAN token — the digital visa.

2. Anyone can verify that visa, without contacting Alice, because the proof is self-contained:

curl -s -X POST https://<YOUR-TRUST-GATEWAY-URL>/v1/ucan/validate \
  -H "Content-Type: application/json" \
  -d '{
    "ucan_token": "<the token from step 1>",
    "required_resource": "google_calendar",
    "required_action": "create_event"
  }'

3. The agent proposes the actual action. The Gateway checks the visa and, if everything lines up, mints the short-lived execution pass:

curl -s -X POST https://<YOUR-TRUST-GATEWAY-URL>/v1/actions/propose \
  -H "Content-Type: application/json" \
  -d '{
    "action_name": "google_calendar_create_event",
    "arguments": {
      "summary": "Architecture Review",
      "start_time": "2026-09-01T14:00:00Z"
    },
    "ucan_token": "<the token from step 1>"
  }'

That's it — three calls, entirely served by the open-source gateway, and you've reproduced the whole "mint a scoped permission, verify it, use it once" cycle. The full API also lets an agent prove it holds one specific capability without revealing the rest of its passport (handy if it's carrying visas it shouldn't disclose), and lets you inspect an agent's live passport at any time. Both are just extensions of the same idea. Turning that final execution pass into a real side effect (actually touching Google Calendar) is the one piece that needs something outside the gateway — a downstream tool consumer to carry it out — but the entire token lifecycle and governance you just exercised runs on trust_gateway alone.

Open source

Everything described in this article — UCAN minting and validation, delegation, and execution-grant issuance — lives in the open-source Trust Gateway, written in Rust and runnable locally today:
👉 github.com/fcn06/trust_gateway

The takeaway

Don't hand AI agents permanent, all-powerful API keys. It's the equivalent of giving an intern your master password.
Give them a passport of short-lived, narrowly scoped visas instead — cryptographically signed, automatically expiring, and impossible to widen through delegation.
Check every action at the door, with a lightweight gateway that turns a valid visa into a single-use, single-action execution pass. The agent still acts on its own. It just can't act beyond what it was actually trusted to do — and that trust is provable, not just assumed.

I'd like your feedback

This is still a work in progress, and I'd genuinely like to hear from people who read this — whether you build agents, work in security, or just have an opinion. A few specific things I'm unsure about:

The core idea: Does scoping AI agent permissions with short-lived, delegatable visas (UCANs) actually solve a problem you've run into, or does it feel like overkill for how you use agents today?
The explanation: Was the passport/visa analogy clear, or did it break down somewhere once the delegation and execution-grant parts came in?
The gaps: What's missing that would make you trust this in production — key rotation, revocation before expiry, auditability, something else?
The demo: If you tried the three curl calls yourself, did they work as described? Anything confusing about the request/response shapes? Comments here are the easiest way to reach me, but I'll also take issues or pull requests on the GitHub repo. If you spend five minutes poking holes in this, I'll read every one of them.

You Don't Need to Choose Between a Gateway and an Agent Framework

fcn06 — Fri, 21 Aug 2026 15:32:51 +0000

When I first published Swarm on GitHub, most questions weren't about Rust or MCP. They were about timing and categorization:

"We just need a lightweight gateway for multi-provider routing; agents feel like overkill."

"We already run an orchestration framework; why would we replace our proxy?"

This reaction highlights a false dichotomy currently plaguing the AI infrastructure ecosystem: the assumption that a gateway and an agent orchestrator must be two completely different products.

In practice, teams rarely wake up needing full-blown multi-agent autonomous swarms on Day 1. But when they start with a standalone proxy, they inevitably hit a wall — patching together Python microservices, external vector state stores, MCP bridges, and ad-hoc eval scripts. Every evolution requires a rewrite.

The core premise of Swarm is different: a single, pure-Rust runtime where you don't choose between a gateway and an orchestrator — you simply choose which capabilities to turn on.

The AI Adoption Ladder

Most engineering teams evolve their LLM stack along a predictable trajectory:

Rung 1: OpenAI-Compatible Gateway   (Drop-in replacement for hardcoded SDKs)
  └── Rung 2: Multi-Provider Fallbacks (Groq, Gemini, Ollama, vLLM via TOML)
        └── Rung 3: Stateful Sessions     (Previous response chaining & context)
              └── Rung 4: Native MCP Tools    (SSE + Streamable HTTP tool execution)
                    └── Rung 5: Multi-Agent DAGs  (Planner + Executor + Specialists)
                          └── Rung 6: Built-in Evals    (LLM-as-a-Judge & policy gates)

You can stop at any rung and have a lean, production-grade binary. When you're ready for the next level, you change a configuration flag — not your architectural foundation.

Rung 1 — Just a Low-Latency Gateway

If your immediate goal is simply eliminating hardcoded API keys and single-vendor SDK locks, Swarm acts as an OpenAI-compatible drop-in front door with sub-millisecond native routing overhead.

# Spin up the gateway in seconds
./kickstart/gateway_kickstart/01_launch_gateway.sh

curl -X POST http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [{"role": "user", "content": "Explain progressive disclosure in software."}]
  }'

You get instant OpenAI compatibility. No agent overhead, no background worker queues, no forced abstractions.

Rung 2 — Multi-Provider & Local Model Routing

When rate limits hit or you need cost-effective fallbacks across cloud and local runtimes (Groq, Anthropic, Gemini, Ollama, vLLM, llama.cpp), routing is declared cleanly in config.toml:

[providers.groq]
api_url = "https://api.groq.com/openai/v1/chat/completions"
weight = 80

[providers.local_vllm]
api_url = "http://localhost:8000/v1/chat/completions"
recommended_models = ["meta-llama/Llama-3.3-70B-Instruct"]

Your applications continue calling the same /v1/chat/completions endpoint. Failover, load distribution, and local-inference routing happen invisibly inside the runtime.

Rung 3 — Stateful Conversations via `/v1/responses`

Multi-turn chat state is where teams often bolt on an external Redis or PostgreSQL session manager. Swarm provides explicit turn-by-turn state management natively through /v1/responses using previous_response_id chaining:

curl -X POST http://localhost:8080/v1/responses \
  -H "Content-Type: application/json" \
  -d '{
    "model": "groq/llama-3.3-70b-versatile",
    "input": "Calculate the Q3 cloud infrastructure spend.",
    "previous_response_id": "resp_01JMW892KPA7XYZ"
  }'

State is managed by the runtime, eliminating client-side conversation bloat while keeping state inspection simple and deterministic.

Rung 4 — Native Model Context Protocol (MCP)

When your model needs real-world context — database schemas, filesystem access, API calls — you shouldn't have to migrate to a heavy agent framework just to call tools.

Swarm natively supports MCP (over both SSE and streamable HTTP) directly inside the gateway layer:

[mcp_servers.postgres_db]
transport = "sse"
url = "http://localhost:3001/sse"

[mcp_servers.git_tools]
transport = "http"
url = "http://localhost:3002/mcp"

Tool discovery, argument validation, and streaming tool execution run within the same engine that routes your completions.

Rung 5 — Coordinated Multi-Agent Workflows

When single-prompt loops cannot solve compound tasks, Swarm activates its autonomous orchestration engine:

User Intent
   │
   ▼
[ Planner ] ──► Builds Execution DAG (Dependencies & Concurrency)
   │
   ▼
[ Executor ] ──► Dispatches tasks across Domain Specialists
   │
   ├── Specialist A (Data Analyst + Postgres MCP)
   └── Specialist B (Report Writer + File MCP)
   │
   ▼
Unified Response

Why this matters: Rung 5 reuses the identical provider configurations, fallback pools, state engine, and MCP tool connectors established in Rungs 1–4. There is no secondary agent daemon or translation bridge.

Rung 6 — Built-in LLM-as-a-Judge Evaluation

The final rung is the one most gateways and agent frameworks omit entirely: closing the loop on quality.

Instead of exporting logs to an external SaaS pipeline, Swarm embeds an LLM-as-a-Judge loop. It scores intermediate DAG outputs, validates MCP tool results against deterministic schemas, and flags hallucinated responses before they reach client applications:

curl -X POST http://localhost:8080/v1/eval/judge \
  -H "Content-Type: application/json" \
  -d '{
    "response_id": "resp_01JMW892KPA7XYZ",
    "criteria": ["correctness", "grounding", "conciseness"],
    "judge_model": "openai/gpt-4o"
  }'

This foundational layer enables our upcoming roadmap items: policy-based dynamic routing, durable state checkpoints, and human-in-the-loop validation gates.

Architectural Coherence Beats Glue Code

The individual capabilities of Swarm — gateway proxying, MCP tool invocation, DAG planning, automated evaluation — exist across different open-source projects.

What is rare is finding them integrated into a single, zero-dependency, memory-safe binary where adopting multi-agent orchestration doesn't invalidate the proxy architecture you set up on Day 1.

The architectural bet of Swarm is simple: the tools you choose when you only need a gateway should never become technical debt the day you need agents.

Discussion

If you're currently scaling your LLM infrastructure:

At which rung on this ladder has your team spent the most engineering time?
Have you had to replace a gateway when moving to agents (or vice-versa)?

Check out the project and try the kickstart scripts on GitHub: github.com/fcn06/swarm

Introducing Swarm: Multi-Agent Orchestration and an LLM Gateway in Pure Rust 🦀

fcn06 — Tue, 18 Aug 2026 05:48:26 +0000

While experimenting with multi-agent systems, I kept ending up with two separate pieces of infrastructure: an orchestration layer for agents and tools, and a gateway layer for routing LLM requests.

I wanted both to share the same runtime, provider abstractions, state management, and protocol contracts.

So I built Swarm, an open-source AI orchestration framework and model gateway written in Rust.

The Dual-Mode Architecture

Many AI stacks end up separating these concerns: a dedicated proxy for lightweight routing and a separate orchestrator for more complex reasoning. Swarm unifies both patterns around a single high-performance Tokio runtime.

+--------------------------------------------------------------------------------------------------+
|                                        SWARM MODES                                               |
+--------------------------------------------------------------------------------------------------+
|                                                                                                  |
|   MODE 1: MULTI-AGENT & MCP ORCHESTRATION               MODE 2: MODEL GATEWAY SERVER             |
|   (kickstart/multi_agent_orchestration_kickstart/)      (kickstart/gateway_kickstart/)           |
|                                                                                                  |
|   • Planner Agent (Dynamic plan generation)             • POST /v1/chat/completions (OpenAI)     |
|   • Executor Agent (Workflow DAG execution)             • POST /v1/responses (Open Responses)    |
|   • Domain Specialists with MCP Tool integration        • Stateful multi-turn chaining          |
|   • Discovery & Memory services                         • Multi-provider (Groq, Gemini, OpenAI,  |
|   • Evaluation & Judge Service                            Ollama / vLLM / local endpoints)       |
|   • Resilient OAuth2 / JWT authentication               • High-throughput lock-free cache        |
|                                                                                                  |
+--------------------------------------------------------------------------------------------------+

The key idea: Swarm can run as a full agent orchestration stack or as a standalone LLM gateway without requiring two unrelated frameworks.

Mode 1: Deterministic Multi-Agent Orchestration with MCP

Coordinating multiple agents becomes much easier when service boundaries and message contracts are explicit.

Mode 1 splits responsibilities across decoupled, specialized services:

Planner Agent: Analyzes incoming user requests and dynamically constructs execution DAGs.
Executor Agent: Resolves task dependencies and controls step execution.
Domain Specialists : Execute live tools via a native Model Context Protocol (MCP) runtime (supporting SSE and streaming tool calls).
Discovery & Memory : Maintain service registries and conversational state.
Evaluation Service : Built-in LLM-as-a-Judge validation loop for output verification and self-correction.

Inter-agent communication relies on type-safe agent-to-agent (A2A) message contracts, catching many contract and integration errors during development and compilation.

User Request
    ↓
Planner
    ↓
Execution DAG
    ↓
Executor
    ↓
Weather Agent
    ↓
MCP Weather Tool
    ↓
Evaluation
    ↓
Final Response

Mode 2: OpenAI-Compatible Model Gateway

Mode 2 exposes an OpenAI-compatible gateway for client applications, developer tools, and automated pipelines.

OpenAI Compatibility (POST /v1/chat/completions): Works with standard OpenAI SDKs, Cursor, and developer extensions.
Stateful Responses (POST /v1/responses): Supports multi-turn conversation chaining using explicit previous_response_id references.
Unified Multi-Provider Routing: Route requests across Groq, Google Gemini, OpenAI, or local backends such as Ollama, vLLM, and llama.cpp through TOML configuration.

[server]
bind_address = "0.0.0.0:8080"
log_level = "info"

[models]
default_model = "openai/gpt-oss-20b"

[providers.groq]
api_url = "https://api.groq.com/openai/v1/chat/completions"

[providers.google]
api_url = "https://generativelanguage.googleapis.com/v1beta/models"

[providers.custom]
# Local inference (Ollama / vLLM / llama.cpp / LocalAI)
api_url = "http://localhost:11434/v1/chat/completions"
recommended_models = ["llama3.2:latest", "mistral:latest", "deepseek-r1:8b"]

Why Rust?

Rust gives Swarm a few useful properties for orchestration and gateway workloads:

⚡ Low-Overhead Request Handling: Built on Tokio and Hyper for asynchronous, high-concurrency gateway workloads.
🔒 Concurrent Session Management: DashMap and Arc-based stores allow shared state across concurrent requests without a global application lock.
🪶 Small Runtime Footprint: No garbage collector and predictable memory ownership make the gateway suitable for lightweight deployments.
🛡️ Strongly Typed Protocols: Internal MCP and A2A message contracts reduce schema mismatches and integration errors.

Quickstart

You can test either mode locally in minutes:

git clone https://github.com/fcn06/swarm.git
cd swarm

# Configure your provider keys
cp .env.example .env

Option A: Launch the Model Gateway (Mode 2)

./kickstart/gateway_kickstart/01_launch_gateway.sh

# Test OpenAI-compatible completions
curl -X POST http://localhost:8080/v1/chat/completions   -H "Content-Type: application/json"   -d '{
    "model": "openai/gpt-oss-20b",
    "messages": [{"role": "user", "content": "Explain Swarm architecture in 2 sentences."}]
  }'

Option B: Launch Multi-Agent MCP Suite (Mode 1)

# Launch agents, MCP server, and infrastructure services
./kickstart/multi_agent_orchestration_kickstart/01_launch_all.sh

# Run a live MCP tool test query
./kickstart/multi_agent_orchestration_kickstart/02_test_weather_query.sh "What is the current weather in Boston ?"

Open Source & Community

Swarm is fully open-source under the Apache-2.0 license. We rely on and contribute back to the emerging Rust AI ecosystem, including the official MCP Rust SDK and A2A Protocol.

I'm especially interested in feedback from people running agent systems or LLM gateways in production:

Would you rather deploy the orchestration and gateway as one runtime, or keep them completely separate?

If you try Swarm, I'd also love feedback on the MCP runtime, gateway compatibility, and APIs.

Stop Giving AI Agents Your API Keys: Introducing Trust Gateway.

fcn06 — Mon, 10 Aug 2026 15:44:10 +0000

AI agents are getting increasingly capable at calling tools: issuing refunds, updating tickets, sending emails, modifying infrastructure, querying databases, and triggering deployment pipelines.

But there’s a security problem I kept coming back to:

Why should the agent itself possess the credentials needed to perform those actions?

If an agent has a Stripe key, GitHub token, cloud credential, or database password, then the security boundary is effectively inside the agent runtime.

I wanted to see if there was a cleaner way to decouple intent from execution, so I started building a small side project called Trust Gateway.

It’s very much a work in progress, and I’m sharing it early to get feedback from the community on the core design, hear how others are approaching this, and learn where it can be improved.

The idea

Trust Gateway separates proposing an action from having authority to execute it.

The model is simple:

Agents propose. Gateway decides. Executors verify.

Instead of giving an AI agent a downstream API key, the agent submits a structured ProposedAction to the gateway.

The gateway evaluates that action against policy.

If it is allowed, the gateway issues a short-lived, cryptographically signed ExecutionGrant bound to the exact tool and parameters that were approved.

The gateway dispatches the granted action to the appropriate executor. Before any side effect, the executor independently verifies the grant's signature, expiry, audience, tool binding, argument hash, and single-use nonce.

┌────────────┐       ProposedAction       ┌───────────────┐
│  AI Agent  │ ─────────────────────────▶ │ Trust Gateway │
└────────────┘                            └───────┬───────┘
                                                │
      No downstream credentials                 │ GrantedAction
                                                │ + ExecutionGrant
                                                ▼
                                        ┌───────────────┐
                                        │   Executor    │
                                        │ owns API key  │
                                        └───────┬───────┘
                                                │
                                                ▼
                                               API

The important part is that the executor does not trust the agent when it says:

“This action was approved.”

It verifies the authorization itself.

Why I think this matters

Imagine an agent with a tool like:

stripe.refund(  
    payment_id="...",  
    amount=50000  
)

There are several possible policies you might want:

Reading a customer record → automatically allowed
Refunding €5 → automatically allowed
Refunding €500 → requires human approval
Refunding €50,000 → always denied
Calling a tool with unexpected parameters → denied

But even if you implement those policies inside your agent framework, the agent may still hold the credential that bypasses them.

Trust Gateway moves that authorization boundary outside the agent.

The agent can ask.

It cannot simply decide.

What an integration looks like

The Python SDK lets you guard a tool using a decorator:

from trust_gateway.client import TrustGatewayClient, guard_tool

client = TrustGatewayClient.dev_mode(  
    gateway_url="http://localhost:3060"
)

@guard_tool(client, "stripe_refund")  
def process_refund(amount: int, order_id: str):  
    return {  
        "status": "refunded",  
        "amount": amount  
    }

Now when an agent attempts:

process_refund(  
    amount=500,  
    order_id="ord_123"  
)

the function is not automatically executed.

Trust Gateway first evaluates the proposed action.

A policy can return something like:

require_approval

and no execution grant is issued until the required approval exists.

Execution grants

I wanted authorization to be independently verifiable, rather than just another HTTP response saying "approved": true.

So Trust Gateway defines an Execution Authorization Protocol with:

structured ProposedAction objects
deterministic canonical JSON
SHA-256 input hashing
Ed25519 signatures
short-lived grants
single-use jti nonces
grants bound to the exact tool and parameter set

That means an authorization for:

{  
  "tool": "stripe_refund",  
  "amount": 500  
}

cannot simply be reused to execute:

{  
  "tool": "stripe_refund",  
  "amount": 50000  
}

The parameters are part of what is authorized.

Human-in-the-loop without putting humans everywhere

I also wanted HITL to be a policy decision rather than the architecture itself.

Not every tool call should trigger a Slack message asking someone to click Approve.

For example:

search_docs → allow

read_customer → allow

send_email → require approval

stripe_refund < $20 → allow

stripe_refund >= $20 → require approval

delete_database → deny

The gateway can distinguish between routine actions and high-impact mutations.

Quickstart

You can run it locally with Docker:

git clone https://github.com/fcn06/trust_gateway.git
cd trust_gateway
docker compose -f deploy/docker-compose.yml up -d

Then install the Python SDK:

pip install -e sdks/python

There’s also a standalone Docker demo if you don’t want to install Rust.

What Trust Gateway is — and isn't

Trust Gateway isn't intended to make an LLM itself trustworthy.

It also isn't a replacement for:

sandboxing
IAM
secret management
network isolation
application-level authorization

Instead, it addresses a narrower problem:

How do we let an autonomous or semi-autonomous agent request privileged actions without giving that agent unrestricted possession of the authority required to perform them?

That is the security boundary I'm exploring.

Where I'd love feedback

The project is still evolving, and I’m especially interested in feedback from people building:

AI agents with real side effects
MCP/tool servers
internal developer platforms
financial or support automation
agentic DevOps workflows
security infrastructure for autonomous systems

I’d particularly love opinions on the protocol design and threat model.

GitHub:

https://github.com/fcn06/trust_gateway

If you're building agents that can do more than just generate text, I'd be curious:

Where do you currently put the authorization boundary between the model and the systems it can modify?

#ai #mcp #god-mode #agents #opensource

DEV Community: fcn06

What If the Enterprise API of the Future Is an Agent?

The current model

Agents change something important — but not the part people assume

A possible future interaction

Where this sits relative to MCP and A2A

Agents propose. Gateway decides. Executors verify.

Agents negotiate meaning, not authority

What we've prototyped so far

The harder problem may be semantic, not cryptographic

Why this could change integration

A brief note on interfaces beyond APIs

There are still many hard questions

Why we think this is worth exploring

We'd like your feedback

Stop Giving AI Agents Your Master Password: UCAN Delegation

The problem, in one picture

The idea: give agents a passport, not a master key

A narrower visa for a narrower job: delegation

What actually happens when the agent tries to act

Trying it yourself

Open source

The takeaway

I'd like your feedback

You Don't Need to Choose Between a Gateway and an Agent Framework

The AI Adoption Ladder

Rung 1 — Just a Low-Latency Gateway

Rung 2 — Multi-Provider & Local Model Routing

Rung 3 — Stateful Conversations via /v1/responses

Rung 4 — Native Model Context Protocol (MCP)

Rung 5 — Coordinated Multi-Agent Workflows

Rung 6 — Built-in LLM-as-a-Judge Evaluation

Architectural Coherence Beats Glue Code

Discussion

Introducing Swarm: Multi-Agent Orchestration and an LLM Gateway in Pure Rust 🦀

The Dual-Mode Architecture

Mode 1: Deterministic Multi-Agent Orchestration with MCP

Mode 2: OpenAI-Compatible Model Gateway

Why Rust?

Quickstart

Option A: Launch the Model Gateway (Mode 2)

Option B: Launch Multi-Agent MCP Suite (Mode 1)

Open Source & Community

Stop Giving AI Agents Your API Keys: Introducing Trust Gateway.

The idea

Why I think this matters

What an integration looks like

Execution grants

Human-in-the-loop without putting humans everywhere

Quickstart

What Trust Gateway is — and isn't

Where I'd love feedback

Rung 3 — Stateful Conversations via `/v1/responses`