The Loop Never Changed — Curation Labs

CURATION LABS · GATEWAY-CENTRIC WORKERS

The loop never changed. What goes into it did.

Input

→

Model

→

Output

a tool runs; its result joins the input

Four designs for AI workers over the last eighteen months, from one session to one gateway, and the contract we still have to write.

Remy · Curation Labs · ~40 min, then discussion

Good [morning/afternoon]. Thanks for carving out forty minutes. I want to spend them on one picture, because it's the clearest way I've found to explain four different things we've shipped without re-explaining the basics four times. Every AI worker we've built in roughly the last year and a half is the same loop: something goes in, the model runs, something comes out, and it feeds back in. What changed, four times over, is what sits around that loop, and who decides what's allowed back in. We'll walk four designs we actually built, borrow one lesson at a time from Sierra's own gateway team, and land on the one open question I want this room arguing about right after I stop talking: the contract between our gateway and our worker's memory. No logos, no roadmap dates I can't back up — just the picture, and an honest line between what's built and what's still a drawing.

OPEN

Every agent we have built runs the same loop: input, model, output, and back.

Context

Everything the model sees on this one call — not everything it’s ever seen.

Everything today is this picture, zoomed. The model knows only what is in the input, this call.

Remy’s brief; report §11.1

[→] Here’s the loop. Three boxes: input, model, output. Whatever the model answers with, this is everything it had to work with — nothing more.

[→] I’ll call that first box context: everything the model sees on this one call. Not everything it’s ever seen — everything sitting in front of it right now.

[→] The model does one of two things with what it sees: it writes text back to a person, or it makes a tool call — the model asking to run something outside itself: a search, a message, a file read.

[→] And here’s what makes it a loop and not a line: when a tool runs, its result doesn’t vanish. It joins the input, and the model sees it on the next turn. Output feeds back into input.

[→] Everything today is this picture, zoomed. Four different designs, one loop underneath — what changes, phase by phase, is what surrounds it, and what’s allowed to feed its input. The model knows only what’s in the input, this call.

OPEN

Two questions decide what a worker can do: what goes in, and who allows it.

illustrative · every Monday, brief Alice on the Acme account and draft the update

—
use Slack, Linear and Gmail
—
run every Monday on its own
—
remember last Monday’s brief
—
stay inside Acme, act as Alice, and hold the email for approval

We’ll run this one task through four designs.

report §10.4, §10.5

[→] Everything that happens to this worker comes down to two questions. Gold, on the input itself: what goes in?

[→] Violet, on the tool edge: who says it may?

[→] One task, illustrative — I’ve made up the names and the numbers, the shape is real: every Monday, brief Alice on what changed for the Acme account across Slack, Linear and Gmail, and draft the customer update. Four things it needs, none checked off yet: use those three tools at all; run itself every Monday without Alice setting it up; remember what it told her last time; and — the sharp one — read Acme and never Globex, act under Alice’s own authority, not swamp its own input with every message it finds, and hold that email for approval before it sends.

[→] We’ll run this one task through four designs.

ACT ONE · TWO IDEAS

Good agents build their input before every call instead of piling up history.

Piled up

… overflowing

user said… model said… tool call tool result

Built

instructions state memory results

ƒ(shelves) → this call’s input

instructions memory: Acme, last Monday

One of the biggest challenges in building Pinecone was making sure it had access to the right context, which is the lifeblood of any great agent.

Sierra · Building Sierra’s MCP gateway (Pinecone is Sierra’s own internal agent, not the vector database)

Phase 3 is when we started building it on purpose.

report §12.2 slide 4; Sierra capture, intro paragraph; 034_2 §1

[→] Two ways to fill an input. On the left, accumulate: whatever happened lands in order — what the user said, what the model said, what a tool returned — stacked the way it occurred, nothing picked or chosen. [→] On the right, construct: a function looks at a set of shelves — instructions, working state, memory, past results — and decides what belongs in this call, in what order, and how much of it. [→] Sierra put it plainly, describing the internal agent they built to make employees more effective: "…making sure it had access to the right context, which is the lifeblood of any great agent." Not what piled up. What you built on purpose. [→] Phase three is when we started building it on purpose.

ACT ONE · TWO IDEAS

Every piece of context needs two checks: is it allowed, and is it useful now?

candidate

→

allowed?

policy · the gateway

→

useful now?

strategy · the runtime

→

input

one refund policy, four ways into the input

whole document

one-line skill

callable tool

two paragraphs

Keep the gates apart and you can change the second without touching the first.

report §12.2 slide 5; 034_2 §6, §28

[→] Every piece of context that might go into the input passes two separate gates. Violet, first: may it? That's policy — is this worker even allowed to see this, full stop, regardless of what it's doing right now. Gold, second: should it, right now? That's strategy — given that it's allowed, is this a useful form of it for this particular call. [→] Same policy, four different shapes into the input, and none of them touch whether it's allowed: the whole document, a one-line skill, a callable tool, or two retrieved paragraphs. Should-it-now can change every day, as we learn better ways to summarize or rank. May-it barely changes at all — it's tied to who the worker is and what it's been granted, not to how good our retrieval code is this week. [→] Keep the gates apart, and you can change the second one — how something's presented — without ever touching the first — whether it's allowed. Collapse them into one system, and every improvement to presentation risks quietly becoming a new permission.

ACT ONE · TWO IDEAS

Sierra connects 89% of its employees’ agents to 45 services through one gateway.

89%of employees use it weekly

Agent Linter Agent Releases Ashby ClickHouse GitHub Gmail Google Calendar Google Drive Grafana Incident.io Linear PagerDuty Pinecone Slack Salesforce AWS OpenSearch

45services connected

SOURCE

Mihai Parparita · Sierra · 22 Jul 2026

Pinecone = Sierra’s internal agent, not the vector database

MCP

Model Context Protocol: the open, standard way an agent finds and calls a tool.

gateway

One service that sits between every agent and the outside world, deciding what it may reach and what comes back.

Instead, we built one gateway for everyone.

Every team could have built its own permission model. They built one.

Sierra · Building Sierra’s MCP Gateway: An engineering iceberg, Mihai Parparita, 22 Jul 2026 · report §8

[→] This is Sierra, the customer-service AI company. Mihai Parparita published this on their engineering blog on the twenty-second of July, and called it an engineering iceberg: a gateway — one service that sits between every agent and the outside world and decides what’s allowed. Two numbers to hold onto: eighty-nine percent of their employees use it weekly, across forty-five different services — the console lists Agent Linter, Ashby, ClickHouse, GitHub, Gmail, Grafana, Linear, PagerDuty, Pinecone and Slack among them, and the post’s own text adds Salesforce, AWS and OpenSearch. That’s evidence the pattern scales at a company that size — not a schedule for us to match.

[→] One heads-up before the quotes start: when Sierra says Pinecone, they mean their own internal agent — the thing Slack and email and GitHub all get routed through. Not the vector-database company. Different Pinecone, same name.

[→] Here’s why they built it. Every team at Sierra wanted their agents talking to something different — sales to the CRM, engineers to the data warehouse. In their own words: “Instead, we built one gateway for everyone.” Every team could have built its own permission model. They built one.

ACT ONE · TWO IDEAS

Most of Sierra’s gateway is hidden work, and much of it controls what agents see.

MCP one “Connect” button tool calls SSO

users vs. service accounts role-gated services OAuth 2.1 server dynamic client reg per-user credential grants optional scope groups serialized token refresh scoped read-only tokens customer tagging multi-tier classification data sensitivity levels cross-customer blocking out-of-band approval audit log + Slack feed pre-authorized workflows summarize, don’t dump question sanitization draft-only sends tool block & replace resume false positives proxied MCP servers REST extensions OpenAPI generic call composite connectors sidecar supervision readiness handshakes multi-region fan-out service owners self-service docs search-stack reuse compatibility shims session persistence heartbeats & keepalives cached tool listings lazy discovery per-connector timeouts tool-name prefixing read-only annotations file refs, opaque optimistic-lock retries MCP Inspector usage analytics rate-limit diplomacy kill switches living arch doc

who may

which tools

tool block & replace proxied MCP servers REST extensions OpenAPI generic call composite connectors service owners self-service docs search-stack reuse cached tool listings lazy discovery tool-name prefixing read-only annotations

run it

sidecar supervision readiness handshakes multi-region fan-out compatibility shims session persistence heartbeats & keepalives per-connector timeouts optimistic-lock retries rate-limit diplomacy kill switches

shape the result

customer tagging multi-tier classification data sensitivity levels cross-customer blocking summarize, don’t dump question sanitization draft-only sends resume false positives file refs, opaque

operations

audit log + Slack feed MCP Inspector usage analytics living arch doc

Ours, not Sierra’s: the post never sorts its 45 items this way — full wording in the appendix.

A good part of a gateway decides what the agent gets to see.

Sierra · Building Sierra’s MCP gateway, figure 1 · report §8.2–8.3

[→] Above the waterline, Sierra’s gateway is four things: MCP — the Model Context Protocol, the open, standard way an agent finds and calls a tool — one Connect button, tool calls themselves, and SSO, single sign-on: one login a person already has, reused instead of collecting a new one.

[→] Below the waterline: forty-five more. Identity machinery, a tool catalog, execution plumbing, a whole layer that shapes what comes back. That’s most of the iceberg, and almost none of it is visible from that one Connect button.

[→] Sort those forty-five by what they actually do, and four columns fall out: who may — identity and permission; which tools — the catalog; run it — the plumbing that executes and retries; shape the result — what comes back changes shape before the agent sees it. A fifth, smaller pile is just operations: logging, dashboards. This grouping is ours — Sierra’s own post never sorts its 45 items this way.

[→] Highlight only the items that change what re-enters the model’s next call — tagging, blocking, summarizing, which tools even show up — and about a fifth of the whole iceberg turns gold. That’s the part this talk is actually about.

[→] A good part of a gateway’s job is deciding what the agent gets to see next.

ACT ONE · TWO IDEAS

Sierra’s lessons on identity, approval and context match the problems we hit.

Interactive work runs as the user.

Sierra · Building Sierra’s MCP gateway, Lesson 7

ONE KEY, EVERY ORG ACTING FOR WHOM?

…we want all write or destructive operations to be tied to user intent and approval.

Sierra · Building Sierra’s MCP gateway, Lesson 6

NO APPROVAL PER CALL

An agent can't misuse what it never sees

Sierra · Building Sierra’s MCP gateway, Lesson 3

shapes the next call

Keep these three in mind. Each one knocks down a wall later.

Sierra · Building Sierra’s MCP gateway, Lessons 3, 6, 7 · report §8.4

[→] First, identity: Sierra’s rule of thumb was “Interactive work runs as the user. Scheduled or shared workflows run as service accounts with only the permissions they need.” That’s the two walls we’ll call one key, every org, and acting for whom?

[→] Second, approval, on GitHub: rather than hand an agent full access, Sierra mints it a scoped, read-only credential for exactly the repositories it needs — “This lets it work with familiar tools, but in a safe way.” That’s the wall we’ll call no approval per call.

[→] Third, context: “An agent can't misuse what it never sees” — building a system that knows whose data this is, before deciding what an agent gets to see. That’s context — it comes back as the loop-back on slide twenty-one.

[→] Keep these three in mind. Each one knocks down a wall later.

ACT TWO · FOUR DESIGNS

We will draw all four designs on one diagram so you can see what changes.

gold · new teal · have coral · wall violet · auth dashed · designed struck through · retired

? what goes in?

? who says it may?

Each design moves one thing out of the session.

report §11.1–§11.3

ACT TWO · PHASE 1 · UNTIL JAN 2026

Phase 1: the agent lived in one person’s session and forgot everything afterwards.

CAN

brief Alice, with her own keys

CAN’T

remember last Monday, or run without her

Three walls: it forgets, it’s built by hand, and it runs on Alice’s keys.

report §7.1 (cc-architectures)

[→] Phase one. One person, one session, one loop — a dotted ring around the whole thing, because when this session ends, everything inside it ends too. It runs inside the tools we already had — Claude Code or Codex — one session at a time, not a product of its own.

[→] Alice starts it. She’s the one asking.

[→] Inside the ring: her tools — search, files, whatever’s wired up — her skills, written instructions for one kind of task, loaded in when needed, and her hooks, small rules that fire automatically and add something to the input before she even asks. All three ride inside her session; none of them survive it.

[→] And one more thing inside the ring: a credential — a key that proves she’s allowed to act. Right now it’s just Alice’s own login. Whatever she’s logged into, the agent can touch.

[→] Watch the input fill. Alice: “brief me on Acme.” Then the agent: checking Slack…

[→] A tool call — search Slack. Then a tool result: one thousand two hundred and four messages, all of it landing back in the input.

[→] A skill loads in — account brief — and Alice adds one more line: add Linear too.

[→] Three walls, and they’re the same three every session like this one hits. It forgets — nothing survives when the session closes. It’s built by hand — every skill and hook, wired up by a person, each time. And it runs on Alice’s keys — whatever she can reach, the agent can reach.

[→] Three walls: it forgets, it’s built by hand, and it runs on Alice’s keys.

LENS 1 · PHASE 1

A session’s knowledge must fit in one input, and it disappears when the session ends.

Context window

The model’s entire input for one call, with a hard size limit measured in tokens — the model’s own units of text.

Alice: brief me on Acme

agent: checking Slack…

tool result: 1,204 messages

↪ older turns folded into a summary — compaction

And it all goes when the session does.

report §11.5; Flue compaction, §7.2

[→] Zoom into that input. This is the context window — the model's whole input, and it has a hard size limit, measured in tokens, the model's own units of text. Every strip we saw a moment ago competes for room in the same window. [→] Every strip stacks in, one on top of the last, in the order it happened — the user's line, the agent's line, a tool call, a tool result, a skill loading in. [→] Eventually it fills. When it does, older turns get folded into a shorter summary — compaction — so the window never quite overflows, but detail is already being lost by the time that happens. Nobody's deciding what's worth keeping; the folding just happens by age. [→] And it all goes when the session does. That's the wall Phase three is built to answer.

ACT TWO · PHASE 2 · FEB–JUL 2026

Phase 2: we packaged tools into reusable workers, but every run still started blank.

Harness

The program that drives the loop and calls the model. Codex, Claude Code and Mastra are three we run today.

One wall down. Every run still starts blank.

report §7.1 (containerized-cli-harness)

[→] Phase two. Draw a solid boundary around the whole loop and call it a container — a worker, one loop plus its kit, drawn inside a boundary we control instead of a session Alice owns.

[→] The kit moves with it: tools, skills, hooks, baked into the container image before it ever runs. Nobody wires it up by hand anymore — one wall falls.

[→] Inside, the loop runs on whatever harness — the program that actually drives the loop — was already built: Codex, Claude Code, and a third, custom runtime built on a framework called Mastra. Same loop, borrowed engine.

[→] But every run starts from that same baked-in image. The transcript from last time is gone. Forgets becomes every run starts blank — a narrower wall, not a fallen one.

[→] One wall down. Every run still starts blank.

ACT TWO · PHASE 2 · FEB–JUL 2026

Phase 2 workers ran on schedule, but shared one key and nobody limited their access.

CAN

run every Monday on its own

CAN’T

remember, scope the key, or limit what it touches

Every team could have built its own integrations, permission model, and auditing system…

Sierra

Every run starts blank, every worker shares one key, and nobody decides what it may touch.

report §7.1 (@cch/coordination)

[→] Something new sits outside every worker’s boundary: an orchestrator. It hands a task down — delegate — and reads the result back into a durable log once the worker’s done.

[→] But look at the key. It’s not Alice’s anymore — it’s one shared credential, baked into the deployment, used by every worker that runs from it. Alice’s keys becomes one shared key.

[→] And nothing above the worker decides what that key may reach. No org control — an empty, violet-outlined box, waiting.

[→] Run our Monday brief here: it can run every Monday without Alice lifting a finger. It can’t remember last week, it can’t scope that shared key to just Acme, and nothing decides what it’s allowed to touch. Sierra’s own words fit here too: “Every team could have built its own integrations, permission model, and auditing system…”

[→] Every run starts blank, every worker shares one key, and nobody above the worker decides what it may touch.

ACT TWO · PHASE 3 · FROM JUL 2026

Phase 3: workers gained memory and an org tool catalog, but not their own identity.

Flue

An open-source agent framework that re-runs our agent function before every model call.

Durable Object

A Cloudflare primitive: one conversation's own persistent, single-threaded worker.

It remembers now, and the org has a catalog. But every worker shows the same key, and nobody records whom it acts for.

report §7.2a (worker-rooms-2); we first rejected Flue, then adopted it once a spike ran end to end

[→] Phase three. The container’s label retires — struck through, grey — and the boundary gets a new one: a Flue worker, one Durable Object per conversation. Flue is the open framework our workers run on now; a Durable Object is Cloudflare’s name for one small, always-addressable unit of storage that stays consistent for exactly one thing — here, one conversation. Worth saying plainly: we didn’t start here. We first rejected Flue, because it keeps the source of truth in framework-owned storage, and only adopted it once a spike proved the whole loop end to end on our own platform.

[→] Three shelves appear under the loop: persistent state, memory, and org files — living on that Durable Object, or on R2, Cloudflare’s bucket of files.

[→] A new step appears before the loop: render — the function that runs right before every call to the model and decides what goes in this time. The input regroups: instructions rebuilt fresh, working state, a memory index, recent messages. The kit relabels too — mounted each render, not baked in once.

[→] On the tool edge, a box appears: a tool control plane, an org-wide catalog you can search, describe, and execute against. For the first time, something above the worker decides which tools even exist. No org control falls.

[→] But look at the key — it hasn’t left the worker, it’s just gotten bigger. One shared key per deployment becomes one platform key, every org. Every organization’s worker still shows the same credential.

[→] Two new walls: acting for whom — nothing records which human this call is actually for — and no approval per call — permission is checked for the whole run, never for one specific call.

[→] It remembers now, and the org has a catalog. But every org’s worker shows the same key, nobody records whom it acts for, and approval stops at the whole run.

LENS 2 · PHASE 3

In Phase 3, a function rebuilds the model’s input from saved state before every call.

initial data persistent state transcript memory

durable rebuilt every call

the agent function → instruction document messages mounted tools

export function useMemoryIndex(
	seed: WorkerSessionSeed | undefined,
	enabled: boolean,
	call: SpacesCall = spacesCall,
): void {
	const delivery = useDelivery();
	useAgentStart(async (ctx) => {
		if (!enabled) return;
		const signal = await memoryIndexIntake(
			seed,
			delivery as { kind?: string; type?: string; attributes?: unknown },
			call,
		);
		if (signal) ctx.append(signal);
	});
}

Render

One execution of the agent function, re-run before every model call.

Persistent state is its input. The model sees only what it returns.

worker-rooms-2/apps/worker-runtime/src/runtime/memory-index.ts:175–190 · worker-rooms-2, report §7.2a; Flue re-renders before every model call, docs/reference/agent-api.md:33

[→] Zoom into render itself. On the left, its inputs: data fixed when the conversation started, persistent state, the raw transcript, memory pulled in from that index. [→] All of that runs through one plain function — no server call, just code — and out the other side comes what the model actually sees: the instruction document, the message list, and whichever tools get mounted for this call. [→] One line splits the picture: everything above is durable, saved on the Durable Object; everything below is rebuilt from scratch, every single call. Here's the real shape of it, from our own worker code: one function reads working state and memory back, and returns a string. Nothing fancier than that. [→] Persistent state is its input. The model sees only what that function returns.

ACT TWO · PHASE 3 · FROM JUL 2026

The Monday brief now remembers, but still can’t prove who is asking or wait for approval.

CAN

recall last Monday, open Acme’s files, use the org catalog

CAN’T

prove who is calling, or hold an email for approval

Phase 3 knows what it knows. It still can’t say who is asking, or for whom.

report §10.5; §7.2a (042)

ACT TWO · RECAP

Each phase moved one thing out of the session: tools, then memory, then authority.

UNTIL JAN 2026

Nothing moves out yet.

FORGETS BUILT BY HAND ALICE’S KEYS

FEB–JUL 2026

The kit moves into a container.

EVERY RUN STARTS BLANK ONE SHARED KEY NO ORG CONTROL

FROM JUL 2026

Memory and state move onto durable storage.

ONE KEY, EVERY ORG ACTING FOR WHOM? NO APPROVAL PER CALL

NOW, IN CONSTRUCTION

Authority moves into the gateway.

CONTRACT?

What’s left inside the worker is its authority.

report §10.3; phase windows per Remy per report §10.8

Three rows are already up, and they're worth reading as a sequence, not three separate facts. Phase one moved nothing out of the session — the kit, the memory, the keys all live and die with it. Phase two moved the kit out, into a container: a worker definition somebody could reuse, instead of hand-wiring a session every time. Phase three moved the memory and state out, onto a Durable Object, and gave the org a catalog on top. [→] One row is missing, and it's the one we haven't built yet: phase four moves the authority out — into the gateway. [→] What's left inside the worker, after all three, is its authority. That's the whole plot of this talk in one sentence: first the kit, then the memory, now the authority.

ACT TWO · PHASE 4 · NOW, IN CONSTRUCTION

Phase 4: the gateway verifies each worker, and credentials never enter the model’s input.

Credential

A key that proves who — or what — is allowed to act. Never called a “token” here.

The credential never enters the input. It rides with the call and stops at the gateway.

report §7.3 (model-tools.ts:66; org-custody-do.ts)

[→] Phase four. That tool control plane relabels itself: gateway. Four compartments inside it, all still dashed — designed, not yet built for anything but one action — who may, which tools, run it, shape the result. Even the tool list changes: tools are now listed by the gateway, not carried by the worker.

[→] Watch the key. It leaves the worker entirely and docks inside the gateway — this worker’s identity, verified at the gateway, not a secret the worker holds. The vendor credential moves further still: held by the gateway, never sent to the worker at all. One key, every org falls.

[→] Two violet rails replace it: worker identity plus delegation, running from the runtime into the gateway, and a second rail, the minimum upstream credential, running from the gateway out to the world. The worker never touches either.

[→] Our first tool through this gateway is one we borrowed the idea for: gateway_whoami. Sierra’s very first tool, in their own build, was whoami.

[→] The credential never enters the input. It rides with the call, and it stops at the gateway.

LENS 4 · PHASE 4

A worker may only do what its organization, its person and its grant all allow.

organization ceiling

Gmail

Alice’s permissions

repo Y

Alice’s grant to her worker

Interactive work runs as the user.

Scheduled or shared workflows run as service accounts with only the permissions they need.

Sierra · Building Sierra’s MCP gateway, Lesson 7

This is the gate from August, with the org chart written into it.

built narrowly · canConfer() for one action family

A worker can never grant itself more than the people above it hold.

034 §2; canConfer(), report §7.3; report §10.7

[→] Zoom into who may. Three nested outlines, each smaller than the last: the organization's own ceiling — what it will ever allow — inside that, Alice's own permissions, and inside that, the grant she's made to her worker. [→] A worker can never hold more than the layer above it grants. Call that delegation — a different kind of delegating than the orchestrator handing down a task back in phase two: this is a person handing over some of her own permission, without handing over her own login. [→] Gmail gets blocked at the very outer ring — the organization never enabled it at all. One specific repository gets blocked one ring in — Alice has access, but never granted her worker that particular one. [→] This is the same gate we talked about back in August, with an org chart written straight into it. [→] A worker can never grant itself more than the people above it hold. Acting for whom falls — every call now carries whose authority it's running under.

LENS 3 · PHASE 4

The gateway checks every call as it happens and holds risky actions for approval.

runtime gateway

check

authorize again, at the call — not because the tool showed up in a list earlier

→

run

a brokered credential, held by the gateway, plus an idempotency record — so a retry can’t run it twice

→

prepare → approve → execute

built, for one action: send a message. A human approves between prepare and execute.

→

shape

the result is reshaped before it goes anywhere — designed generally, built only for this one action

solid border · built
dashed border · designed, not yet built

result → input

control → state

…we want all write or destructive operations to be tied to user intent and approval.

Sierra · Building Sierra’s MCP gateway, Lesson 6

Every call is checked when it happens, and every effect waits for its approval.

034 §3, §6, §10–§12; report §7.3 built/designed/open table; Sierra capture, Lesson 6

[→] One call, start to finish. The runtime asks the gateway again — not because the tool showed up in a list earlier, but because listing and permission are two separate checks, every single time. [→] The gateway runs it with a credential it holds itself, never handed to the worker, and stamps the call with an idempotency record — so if the same call gets retried, it doesn't happen twice; the gateway already knows it ran. [→] For the one action we've actually built — sending a message on our own chat platform — there's a third step: prepare, then a human approves, then execute. Built, for that one action. Everything else on this slide is designed, not yet built. [→] Whatever comes back gets shaped before it goes anywhere. Sierra's own line fits exactly: "An agent can’t misuse what it never sees." [→] Then two channels run back, not one — the next slide is about that split. [→] Every call is checked when it happens, not when the tool was listed. No approval per call falls.

ACT TWO · PHASE 4 · NOW, IN CONSTRUCTION

The gateway also shapes what comes back, and that becomes part of the next input.

Artifact

Too big or too sensitive to hand the model directly — kept by the gateway, referenced, re-checked each read.

An agent can't misuse what it never sees

Sierra

What comes back is part of the next input: one channel the model reads, one it never sees.

034_2 §10, §15–§17

[→] The return arrow relabels too: model-visible result — the part of what comes back that the model actually reads. Right now it’s a gateway result: a summary plus a reference, not a raw dump.

[→] A second arrow appears, dotted, running the other way: context effects, straight into persistent state — provenance, sensitivity, what changed — none of which the model ever sees directly.

[→] The shelf gains one more box, still dashed: artifacts — anything too big or too sensitive to hand the model directly, kept by the gateway, referenced instead of inlined.

[→] Watch the tool list itself change, one call at a time: it starts with search_accounts.

[→] Once Acme gets picked, read_acme_data appears — a tool that wasn’t even offered a moment ago.

[→] And only once a human approves, update_acme_account shows up too. Same line as before, and it’s why this slide exists: “An agent can’t misuse what it never sees.”

[→] What comes back is part of the next input: one channel the model reads, one it never sees.

ACT TWO · PHASE 4 · NOW, IN CONSTRUCTION

With the gateway, the Monday brief acts for Alice, stays inside Acme, and waits to send.

illustrative

✓acts as Alice, under her grant ✓never touches Globex ✓a summary, not 18,000 messages ✓holds the email for approval

Every wall is down except the one between the gateway and the loop.

report §10.5; 034 §8, §11

ACT TWO · PHASE 4

Both halves exist today, but separately: a gateway for one action and a worker with memory.

Worker

built · flue-worker-iter1

home & session conversations
durable working state
cross-session memory

CONTRACT?

Gateway

built for one action · sending a Buzz message

identity & tenant binding
grant ∩ ceiling, one action family
custody-held key · approval
idempotency · audit · gateway_whoami

designed, not built

catalog · general credential broker · result shaping

Five parts still open: connection templates & org connections · artifacts with reauthorization · context effects · the useGateway adapter · context manifest / checkpoint / composer.

Neither half calls the other yet.

report §7.3 built/designed/open table · apps/gateway-authority/src/{outcomes,permissions,approvals}.ts

[→] Here's the honest split. Built, narrowly: worker identity, which org a call belongs to, the ceiling-and-delegation check — but only for one family of actions — a credential the gateway holds and never hands out, approval, a ledger that catches retries, an audit trail, and one working tool: gateway_whoami. [→] Built, separately, on the agent's own side: a home conversation and short-lived session conversations, durable working state, and cross-session memory that's been proven live, on a real Durable Object. It works today. It is not yet connected to the gateway at all. [→] Designed, not built: the general version of this gateway — a full catalog, results shaped for every kind of tool, not just one. [→] Open: the five nouns the contract needs, context effects, artifacts with a real read policy, and the hook that would let any Flue worker talk to this gateway without hand-writing the wiring each time. [→] Both halves exist: a gateway that governs one action, and a worker that remembers. Neither knows the other is there yet. The contract is what joins them.

ACT THREE · THE CONTRACT

The gateway decides what a worker may know; the worker decides what to use now.

Gateway owns

what exists
what’s allowed
where it came from
how fresh it is

Runtime owns

what’s useful now
how much fits
how it’s presented

The MCP gateway determines what an agent is allowed to know and do. Flue determines how permitted information participates in the agent loop.

Persist truth; construct context. Do not persist “the context” as though it were the truth.

034 line 54 · 034_2 line 7 · report §9.1, §9.2

[→] Two sentences carry the whole contract. First, ours: the gateway determines what a worker is allowed to know and do. Flue determines how permitted information participates in the loop. [→] Second, put more sharply, from the same design work: persist truth; construct context. Don't persist the context itself as though it were the truth. [→] So: the gateway owns what exists, what's allowed, where it came from, how fresh it is. The runtime owns what's useful right now, how much of it fits, and how it's presented. [→] Neither side should do the other's job. The design docs are blunt about the failure mode if we blur this: build enough construction logic into the gateway, and it stops being a gateway — it becomes a second agent runtime, with its own opinions about how to think, sitting between our worker and the world.

ACT THREE · THE CONTRACT

The contract must stay fixed while our ways of building context keep changing.

Fixed contract

identity authorization context source identities memory scopes provenance artifact references capability definitions canonical transcript operational checkpoint

↓

Changing construction

retrieval ranking progressive disclosure summarization transcript selection memory selection token budgeting model-specific formatting

↓ context → model

The contract is the line between them.

034_2 §37, §40

[→] Split the whole system into two layers. On top, slow-moving and stable: identity, authorization, provenance, artifact references, the transcript, the checkpoint. This is the layer we want to almost never touch, because every consumer downstream — audit, compliance, a future debugging session — depends on it staying put. [→] Underneath, fast, and meant to keep changing: retrieval, ranking, what gets shown first, summarizing, budgeting, formatting. This is exactly the kind of code we'll want to rewrite constantly as models get better and our own workers teach us what actually helps. If better summarization means rewriting a permission check, we've built it wrong. [→] The contract is the line between them. Everything above it is what the gateway and the worker owe each other. Everything below it is free to be wrong today and better next week, without anyone needing to re-approve anything.

ACT THREE · THE CONTRACT

The first version of the contract needs only five parts.

Everything else is an implementation of these.

034_2 §38; report §9.3

[→] Five nouns, pinned straight onto the picture we already know. On the worker itself: a binding — set once, at creation: which org, which worker, which human if any.

[→] Feeding the render: a manifest — fetched fresh at each submission, describing what’s available, not the final prompt itself.

[→] On the return arrow: a tool outcome, split the same way we’ve already seen — one part the model reads, one part only the runtime keeps.

[→] On the artifacts shelf: an artifact, held by reference, re-checked every time it’s read again, not a permanent pass.

[→] And on persistent state: a checkpoint — cursors, not content. It says where you are, not what you saw.

[→] Everything else is an implementation of these five.

ACT THREE · THE CONTRACT · CUTTABLE

One end-to-end test would prove the contract, from creating a worker to re-reading a result.

1–3
binding → manifest → mounted tools
4–7
call → outcome → projection → checkpoint
8–10
re-render → next context → reauthorized re-read

If this loop works, the rest are extensions.

034_2 §39; report §9.3

ACT THREE · THE CONTRACT

Five open questions stand between today’s two halves and a working contract.

1
Who composes context: the runtime, the gateway, or a split?
2
Where does the model/control split live, on the wire?
3
Where does memory live, and who may write it?
4
Whose identity does a worker act under?
5
A useGateway adapter now, or after a second connector?

Contract? is still standing.

report §9.4, §9.6

[→] Contract? is still standing. That's the one we take down together, right after this, not on this slide. Five questions, roughly in the order they depend on each other. [→] Who composes context: the runtime alone, the gateway alone, or some split? [→] Where does the line between what the model reads and what only the runtime keeps actually live, on the wire? [→] Where does memory that crosses conversations live, and who's allowed to write to it — it already works, on the worker's own side, today. Does it move behind the gateway, or stay where it is? [→] Do we design one hook for talking to the gateway now, from a single example, or wait for a second, different one? [→] And whose identity does a worker act under: itself, the way we've built it, or the human, the way Sierra does it? Both give an audit trail. They disagree about who shows up in it, and about what happens the day that human leaves the company. These are the questions for the next hour.

ACT THREE · THE CONTRACT

Our gateway must do what Sierra’s does and also carry context back into the loop.

1
What may come back?
2
Who decides what’s used?
3
What survives the conversation?

The gateway has become what we hoped it would: plumbing.

Sierra · “Releasing the lock”

80% of a workflow rounds down to 0%

Let’s design the contract.

Sierra capture, “Lesson 4” and “Releasing the lock” · report §9.6

[→] Three prompts to start with: what may come back — agree the fields on each channel, the model-visible one and the one only the runtime keeps. Who decides what's used — agree the default composition mode, and when, if ever, the gateway's allowed to rank or summarize on its own. What survives the conversation — agree where memory and artifacts live, and what it takes to read them again once they've aged. [→] Sierra's own line, once the lock came off: "The gateway has become what we hoped it would: plumbing." Ours governs one action end to end today. Theirs got there by adding services, one team's request at a time, until nobody had to think about it anymore. [→] One bar to hold ourselves to on the way there — theirs, not ours yet: eighty percent of a workflow rounds down to zero percent. Half a contract is worth building toward, but it isn't worth shipping. [→] Let's design the contract.

APPENDIX · GLOSSARY

Every term, defined once.

Context: Everything the model can see on one call — assembled fresh each time, not just whatever piled up.
Context window: The model’s fixed limit on how much context fits into one call.
Tool call: One way a model’s output can go: naming a tool and arguments, instead of returning text.
Harness: The program that runs the LLM loop inside a session or a container (Codex, Claude Code, a custom runtime).
Skill: A packaged block of instructions loaded into an agent’s context, usually triggered by a hook.
Hook: A use*-prefixed function that attaches one capability (model, tool, state) inside a Flue agent function.
Flue: The open-source agent runtime, from the withastro GitHub org, our Phase 3 and 4 workers build on.
Render: One execution of Flue’s agent function; the runtime re-runs it before every model call.
Durable Object: A Cloudflare Workers primitive: one addressable, stateful compute unit with its own private storage.

R2: Cloudflare’s S3-compatible object storage; backs the org-wide Spaces filesystem.
MCP: Model Context Protocol: an open protocol connecting an agent to external tools over a standard wire format.
Gateway: The plane that decides what a worker is allowed to know and do, separate from the runtime that builds context.
Credential: A secret proving the right to act as a vendor account; brokered by the gateway, never placed in the model’s input.
Principal: An identity covering both a human user and a service account, for uniform auditing.
Delegation: An org grants a person, a person grants a worker — never more authority than they themselves hold.
Artifact: An addressable, reauthorizable handle for a result or memory too large or sensitive to inline permanently.
Idempotency: A guarantee that a retried effectful call returns the prior outcome instead of repeating the effect.
Epoch: A version marker for one fact, letting a consumer detect it changed without re-checking everything.

One line each, to check a definition after the fact.

report §3, §12.5 A1; Terms introduced, §§5–9

APPENDIX · ICEBERG

All forty-five iceberg items, in full, sorted into our five columns.

Who may 10

Users vs. service-account principals
Role-gated services
OAuth 2.1 authorization server
Dynamic client registration
Per-user credential grants
Optional scope groups (opt-in DMs, private channels, writes)
Serialized token refresh behind distributed locks (rotating refresh-token families)
Scoped read-only token minting (the gh CLI compromise)
Out-of-band human approval (with rationale)
Pre-authorized workflows for automations

Which tools 12

Tool blocking and replacement
Proxied official MCP servers
REST extensions (public and reverse-engineered APIs)
OpenAPI spec + generic call tools (“here’s the documentation, figure it out”)
Composite connectors
Service owners (federated validation)
Self-service doc sets
Production search-stack reuse
Cached tool listings with background refresh
Lazy discovery (never during initialize or ping)
Tool-name prefixing vs. the 64-character limit
Read-only tool annotations (so clients stop over-prompting)

Run it 10

Sidecar process supervision (lazy start, crash budgets, restart backoff)
Readiness handshakes
Multi-region fan-out (injected region parameter)
Client compatibility shims
Session persistence and reuse
Heartbeats and keepalives
Per-connector timeouts (one slow upstream ≠ forty services down)
Optimistic-lock retries on hot session rows
Rate-limit diplomacy
Kill switches and dynamic settings

Shape the result 9

Customer tagging of every tool response
Multi-tier classification (deterministic candidates → fast model → slow model)
Data sensitivity levels / per-service sensitivity ceilings
Cross-customer access blocking
Summarize-don’t-dump tool design
Question sanitization via a single-tasking model
Draft-only email, internal-only Slack sends
Resume false positives (recruiting-data caps)
File refs (out-of-band uploads, opaque handles)

Operations 4

Audit log + open Slack transparency feed
Integrated MCP Inspector
Usage analytics and audit warehouse
Living architecture doc

Gold-edged items (9 of 45) shape what re-enters the model’s next call — the same nine that turn gold on slide seven. This five-column split is ours; Sierra’s post never sorts its 45 items this way.

Nine items, the same nine gold ones from slide seven, decide what the model sees next.

report §8.3; Sierra capture, figure 1 transcription (lines 127–188)

APPENDIX · SIERRA’S LESSONS

Seven of Sierra’s lessons, and what we’ve done with each.

Lesson	One sentence	Our disposition
1 · Grab the lock	One team solving auth, audit and integration for everyone beats every team wiring its own stack.	Present — validates the gateway over direct connections
2 · Coding agents still need humans	Agents cheat at self-verification; smoke-test with weaker agents; keep a living invariants doc.	Process — how we build our gateway, not a diagram wall
3 · An agent can’t misuse what it never sees	Response-level tagging plus multi-pass classification blocks cross-customer leakage.	Present, partly deferred — audit and approval present; summarization adopted; tagging and DLP deferred to multi-customer workflows
4 · 80% of a workflow rounds down to 0%	Partial workflow coverage captures none of the adoption value.	Adopted in part — curated views and REST synthesis adopted; the 80/20 catalog rule itself proposed, not adopted; sidecars/multi-region deferred
5 · Avoid the strategy tax	Deep Pinecone integration without requiring it — any client gets real data day one.	Present — the gateway’s per-worker framing serves any harness, not one
6 · Don’t fight the weights	GitHub’s full MCP server lost to the `gh`/`aws` CLIs agents already know, behind a minted scoped token.	Adopted — scoped-credential egress shape; writes tied to intent present
7 · Human identity and agent identity	Interactive work runs as the user; scheduled or shared work runs as a service account; pre-authorized workflows add a third safeguard.	Present, reframed — principals model present; pre-authorization present in spirit, no named artifact yet; service owners adopted with a stricter review gate

Lesson 7, compared — an open question, not a resolved one. Sierra keys identity to the kind of work: interactive work runs as the user, scheduled or shared work runs as a service account. Our worker design keys identity to the worker itself: the AI worker is the authenticated subject in every case, and a human enters only as delegated authority. Sierra reasons more simply per call; ours keeps one identity and audit trail per worker across interactive and autonomous use. Neither is shown wrong — see slide 28.

Sierra reasons per call; ours keeps one identity and audit trail per worker.

report §8.4, §8.6

APPENDIX · MEMORY CLASSES

Not one memory. Ten classes, each owned somewhere.

Memory / state class	Lifetime	Scope	Canonical owner
Working context	One LLM call	Turn	Flue harness
Conversation history	Conversation	Conversation	Flue
Operational state	Conversation/task	Conversation	Flue `usePersistentState`
Episodic memory	Across conversations	User/worker/org	Gateway context service
Semantic memory	Across conversations	User/worker/org	Gateway context service / systems of record

Memory / state class	Lifetime	Scope	Canonical owner
Procedural memory	Versioned	Organization/worker	Skills / policy–context registry
Artifact memory	Potentially long-lived	Task/user/org	Artifact/resource store
Workspace memory	Task/session	Agent/workspace	Sandbox provider
Capability state	Dynamic	Principal	Gateway
Authorization state	Dynamic	Principal	Gateway

Ten kinds of state this talk used loosely, split by lifetime, scope and owner.

034_2 §3

APPENDIX · RESPONSIBILITY

Who owns what, row by row.

Concern	Gateway	Flue
Tenant isolation	Owns	Enforces conversation access too
Worker identity	Owns	Carries binding
Human delegation	Owns	Carries reference
Tool authorization	Owns	Never overrides
Capability catalog	Owns	Projects into model
External memory store	Owns / mediates	Queries through contract
Memory authorization	Owns	—
Conversation transcript	—	Owns
Conversation control state	—	Owns

Concern	Gateway	Flue
Context strategy	Supplies profile/config	Primarily owns
Token budgeting	Advises	Owns
Model-specific formatting	—	Owns
Raw tool result policy	Owns	—
Model-visible tool result	Defines safe projection	Persists/projects
Artifact storage	Gateway/object store	References
Prompt compaction	—	Owns
Context observability	Shared	Shared

Identity and policy on one side, presentation and ranking on the other.

034_2 §35

APPENDIX · EPOCHS

Eight names proposed. Four already shipping.

034_2 §29’s eight epochs

contract version — the shape of the contract itself
profile version — which composition strategy is pinned
orgConfig epoch — org-wide policy and configuration
authorization epoch — permissions; a revocation invalidates rediscovery
catalog epoch — the tool catalog; a new tool need not invalidate memory
memory epoch — memory candidates; a new memory need not rediscover tools
artifact version — one artifact’s content
tool schema version — one tool’s call shape

Already shipping in the built gateway

policy_revision
catalog_fingerprint
binding_fingerprint
relay_binding_revision

Accumulated independently, without a name for the pattern, in apps/gateway-authority/src/approvals.ts’s row types — Buzz-specific, not yet reconciled with 034_2’s vocabulary (report §9.4 Q5).

Four fingerprint fields shipping today, unreconciled with the proposed eight.

034_2 §29; report §9.4 Q5

APPENDIX · EVIDENCE

The four phases and the repos behind them.

Phase 1

Until Jan 2026 · one session at a time; no product name

cc-architectures 2025-11-01 – 11-30 — Claude Code playground: skills, hooks, 10 subagents

Phase 2

Feb – Jul 2026

codex-container-platform 2026-04-24 — Codex CLI in a Cloudflare Sandbox container
mindblown 04-09 – 06-12 — the flagship live multi-Mind product
darwinian-harness-services 04-28 – 06-17 — session-log analysis harness
containerized-cli-harness 05-21 – 06-26 — container substrate + coordination layer
darwinian-harness-desktop 06-08 – 06-25 — Card Factory authoring app
mindcloud 06-11 – 06-26 — console / deploy management
darwinian-org 07-22 – 08-03 — Architect + Foundry, spans into Phase 3

Phase 3

From Jul 2026

worker-rooms (v1) 2026-08-28 – 08-31 — Mastra-based, rejected Flue by name
worker-rooms-2 08-31 – 09-25 — THE Phase 3 implementation, Flue-based (1,786 commits)
memory, i355 merged 09-22 — PR #88, cross-session memory index
spaces, i409 closed 09-23 — org-wide R2 filesystem
tool control plane, 042 09-03 — internal gateway attempt
buzz 08-06 – 09-23 — identity substrate (not a CL product)

Phase 4

Now, in construction

flue-playground design docs 09-23 – 09-25 — 007 through 034/034_2, gateway architecture lineage
Buzz v1 gateway code last touched 09-25 — one action: send a Buzz message
flue-worker-iter1 09-24 – 09-25 — agent-side worker pattern, proven on a real Durable Object (15 commits)

Without a fixed date: the move to Flue followed an initial rejection of Flue (worker-rooms v1) and then a spike that ran end to end (report §7.2a).

Remy’s phase windows, with the repos that evidence activity inside each.

report §7.1, §7.2a, §7.3, as evidenced in the repos

APPENDIX · CLAIMS

What’s confirmed, and what still needs checking.

MCP protocol revision 2026-07-28 is real, and is what SDK v2 targets

Confirmed

@modelcontextprotocol/* pinned 2.0.0; source map cites it

Mcp-Method / Mcp-Name are real HTTP headers in the SDK

Confirmed

server dist .d.mts:1180,1182

MRTR / input_required exists in the SDK

Confirmed, narrower scope

built for elicitation, not human approval

MCP has a formal reverse-DNS extension-ID mechanism

Needs verification

no occurrence in the installed SDK bundle

MCP tool result content is flattened to text for the model

Confirmed, near-verbatim

@flue/runtime docs, agent-api.md:701

Flue’s turn_request is in-process only, never persisted

Confirmed

@flue/runtime docs, events.md:326

useAgentStart loads data before the model executes; can modify capabilities

Confirmed, close paraphrase

agent-hooks-api.md:271–289

Anthropic’s Managed Agents split the session log from context management the same way

Not independently verifiable

no local Anthropic source to check against

MCP maintainers have an August 2026 roadmap for multiple result representations

Not independently verifiable

no roadmap document available locally

034’s citation markers throughout the document

Uncited — treat with care

citations behind roughly a dozen markers did not survive export

What’s traced to a source, and what still needs one.

report §9.5, §14

The loop never changed. What goes into it did.

Every agent we have built runs the same loop: input, model, output, and back.

Context

Two questions decide what a worker can do: what goes in, and who allows it.

Good agents build their input before every call instead of piling up history.

Every piece of context needs two checks: is it allowed, and is it useful now?

Sierra connects 89% of its employees’ agents to 45 services through one gateway.

MCP

gateway

Most of Sierra’s gateway is hidden work, and much of it controls what agents see.

Sierra’s lessons on identity, approval and context match the problems we hit.

We will draw all four designs on one diagram so you can see what changes.

Phase 1: the agent lived in one person’s session and forgot everything afterwards.

A session’s knowledge must fit in one input, and it disappears when the session ends.

Context window

Phase 2: we packaged tools into reusable workers, but every run still started blank.

Harness

Phase 2 workers ran on schedule, but shared one key and nobody limited their access.

Phase 3: workers gained memory and an org tool catalog, but not their own identity.

Flue

Durable Object

In Phase 3, a function rebuilds the model’s input from saved state before every call.

Render

The Monday brief now remembers, but still can’t prove who is asking or wait for approval.

Each phase moved one thing out of the session: tools, then memory, then authority.

Phase 4: the gateway verifies each worker, and credentials never enter the model’s input.

Credential

A worker may only do what its organization, its person and its grant all allow.

The gateway checks every call as it happens and holds risky actions for approval.

The gateway also shapes what comes back, and that becomes part of the next input.

Artifact

With the gateway, the Monday brief acts for Alice, stays inside Acme, and waits to send.

Both halves exist today, but separately: a gateway for one action and a worker with memory.

Worker

Gateway

The gateway decides what a worker may know; the worker decides what to use now.

Gateway owns

Runtime owns

The contract must stay fixed while our ways of building context keep changing.

Fixed contract

Changing construction

The first version of the contract needs only five parts.

One end-to-end test would prove the contract, from creating a worker to re-reading a result.

1–3

4–7

8–10

Five open questions stand between today’s two halves and a working contract.

Our gateway must do what Sierra’s does and also carry context back into the loop.

Every term, defined once.

All forty-five iceberg items, in full, sorted into our five columns.

Who may 10

Which tools 12

Run it 10

Shape the result 9

Operations 4

Seven of Sierra’s lessons, and what we’ve done with each.

Not one memory. Ten classes, each owned somewhere.

Who owns what, row by row.

Eight names proposed. Four already shipping.

034_2 §29’s eight epochs

Already shipping in the built gateway

The four phases and the repos behind them.

Phase 1

Phase 2

Phase 3

Phase 4

What’s confirmed, and what still needs checking.