Stage 3 of enterprise AI adoption: agents that can read

This is part 3 of a series that started with the full reference diagram in part 0, covered identity and the gateway in part 1, and covered data and retrieval in part 2. Stage 3 covers the boxes marked 3 on that diagram, Agent runtime and Read connectors inside AGENTS & TOOLS. The Agent runtime box is labeled "sandboxed execution," and at this stage it connects only to read-only connectors. This stage comes after data and retrieval because an agent needs something to read before it has anything to do, and what it is allowed to read is bounded by the scoping built in stage 2. Nothing in this stage changes an external system or sends a message, so a mistake here still leaves no external trace.

I use the same company as in parts 1 and 2, Qingchuan, about 40 people, 8 engineers and 2 in marketing. Qingchuan is made up and only serves to walk the stage. Coming out of stage 2, everyone logs in through the identity provider, every call passes through the gateway with a role attached, and questions over internal material return answers scoped to the asker. What Qingchuan does not have yet is anything that acts on its own. Every read is still a person asking one question and getting one answer back.

Agent runtime: sandboxed execution

The first box is where an agent starts running steps without a person driving each one. The label is "sandboxed execution". At Qingchuan that means an agent that can read the repo and query the ticket system on its own, inside a bounded execution environment with a fixed list of what it can reach and a time bound on every run.

The property that matters here is containment. A run that crashes, loops, or follows a bad plan stays inside the box. It cannot reach systems outside the list, and when the time bound trips the run stops. Without this box, every agent run executes with the full reach of whatever machine or credential it borrowed, and one bad run can read far outside the task. This is containment only. Run-level halt on policy grounds, with scope and budget tripwires, belongs to stage 5. Done looks like this: a written list of what the runtime can reach, a time bound that is on by default, and a run that exceeds it stops with a record of what tripped.

Read connectors: scoped by the same roles

The second box connects that runtime to internal systems for reading only. At Qingchuan that means a connector to the repo and a connector to the ticket system, each carrying the same role scoping stage 2 built for the retrieval index. An agent asking as marketing sees what marketing may see. The same agent asking as support sees what support may see.

The order established in stage 2 carries over unchanged. The scoping is enforced by the system, before the agent sees anything. A connector that was never scoped tightly enough is a separate problem from the agent misbehaving, and the agent ends up reading more than intended while doing exactly what it was told. Done looks like this: each connector names the systems it reads and the roles it serves, the same question through two roles returns different material, and removing every instruction about permissions from the agent prompt changes nothing.

The agent's report is not the record

Once an agent runs on its own, what the agent says it did and what the system recorded independently do not always agree, and the gap is quiet because the agent sounds certain.

I ran a small local experiment on this, 20 runs (N=20, single arm) on a local small model, where the task was to finish a file operation and report completion. In 18 of the 20 runs the agent reported done and the file was not there. The fix that closed the gap was a check outside the agent that confirmed the file existed before accepting the report. The numbers come from a lab gate report and describe that setup only. I carry over the shape. The numbers stay with that setup: completion is a fact to be checked outside the agent, never a sentence to be accepted from it. Done looks like this: every run leaves a log of what it read and when, kept where the agent cannot rewrite it, and the log matches what the agent claims, line by line.

The exit check before stage 4

Run this with a real agent and real connectors. Pick a task, let the agent run it, then reconstruct what it read and when from the system log alone, without asking the agent. If the reconstruction and the agent's report disagree, the logging box is not built yet.

The second half is a readiness probe for stage 4, stated here in the same form part 0 uses. Pick one action the agent took and answer from records alone which policy allowed it, at which version, with which inputs. A log line saying the call happened leaves that question unanswered. Until both halves pass with the system doing the recording, stage 4 is not the next thing to work on, because stage 4's approval records inherit whatever this stage failed to capture. Full policy versioning and run-level halt arrive in stage 5.

The AGENTS & TOOLS column is drawn the same on the self-hosted variant of the diagram, and the hosting choice changes little at this stage. The read path stays inside the same systems either way. Part 4 covers write and send connectors with human approval between them, where a mistake leaves an external trace and the records built in this stage become the thing an approval refers to.