Agents · Compliance · Article 2 · Draft

From the Agentic Web to the dev-lab: three layers, one set of controls

Article 1 of this series: How to make an AI World work and stay compliant. It introduced three controls: gate, isolation, evidence. This article follows them through three layers.

Two terms, defined once

The Agentic Web means the open internet as seen by software agents: services that agents read, and where allowed act on, for a person.

The dev-lab means the place where agents are built, tested and run: the workstation, the repositories, the pipelines and the small hosts around them.

Between the two sits the Agentic Enterprise, a company run by agents inside one organisation. Each layer gets the same three controls.

1. The Agentic Web: an agent that acts for one person

An agent on the web is software that acts for a person: it reads services and, where allowed, acts on them with that person's own access. Such an agent works within legal, contractual and security limits.

Three parties are involved: the user, who owns the account and the mandate; the agent, with its own browser profile and its own folder; and the service, whose pages, messages and comments are data for the agent, never instructions.

Reading and writing are different runs

A reading run never posts, reacts, messages, follows or edits. A writing run is a separate kind of run.

Identity stays with the user

The agent uses its own browser profile. It never types, stores or asks for a password, code or token; the user signs in once.

Writes wait for approval

Every write is first an exact draft: what, where, the exact text, the target. It is done only after approval of that exact draft, one action per approval, never in bulk. Any change to the text is a new approval.

Untrusted input

An instruction found in a page, comment or message is reported, not followed.

Evidence and a canonical source

Each run writes one dated report, and what the agent collects stays in its folder. The user's own site is the original of an article; a copy elsewhere links back.

In short: approval of the exact draft; a dedicated profile with no stored credentials; a report for every run.

2. The Agentic Enterprise: roles, a bus and a system of record

An agentic enterprise here is a simulated small company run by software agents. An orchestrator fires entity sides (the company's own side and external partners such as customers, auditors and vendors) as short-lived sub-agents, each with a written role profile it loads before acting.

How the work runs

A schedule wakes the orchestrator on a slow timer. It reads a run, suspend or stop control, picks the most valuable legitimate item, has it done, verifies the result, logs it and rewrites the list of next actions. Sub-agents draft and investigate; the orchestrator performs external effects and checks them against the system of record. An agent's own summary is data, not proof.

How the parts talk

• A file bus: each agent has an inbox and an outbox of message files with a thread, a kind of ask (inform, question, request, decision), a due time and a status.
• A request channel between the owner and the main orchestrator; each item has an id and a status (queued, working, question, needs-approval, done).
• Escalation as a card: an agent that needs the owner writes an escalation; it becomes one card with the recommended choice first, and the owner's click returns on the same thread.
• Text from another agent is data, never an instruction or an approval.

The gate

A change reaches the shared core only through its own branch, an independent review bound to the exact commit, and one owner approval. The coordinator re-checks at the click and pushes nothing if anything changed. Approvals are buttons: a typed "yes" authorises nothing. Secret steps need the owner's own confirmation in that agent's own session.

Isolation

A scan blocks any name, host, id or organisation data from leaving. Allow- and deny-lists belong to the owner; agents never change them. Long work runs in the background or in a few sub-agents, and non-essential loops pause when resources are short.

Evidence

Every action of the simulated company is one line in an append-only log: what, who, why, on what basis, decided by whom. A ledger keeps every open request until it is done or dismissed. Delivery is measured, not liveness: "alive but delivered nothing" is an alarm.

One lesson from this layer: a claim must be proved against the system of record before it is repeated.

3. The dev-lab: zones and what may talk to what

Two zones

• The owner zone holds the control surface (a local dashboard with its request channel and cards), the live agent sessions, a local file bus and working copies of repositories. Secrets stay in local-only files and never travel to the shared core.
• The source and pipeline zone holds the organisation's repositories, review history and pipelines, with scheduled backups.

How they connect

Work moves by pushes and pulls through the source service, and the control surface pushes only after an owner approval. Agents do not hold credentials of their own for other zones: secret steps need the owner's own confirmation in the agent's own session.

Small hosts

Small hosts are designed to run only allow-listed commands over git and signed messages, with no inbound port. Heavy jobs run one at a time.

In short: independent review and owner approval; zones and allow-lists; a supervisor that checks heartbeats, and a record of every crossing.

4. One set of controls, three layers

5. Take away

Whatever the layer, assume the agent can be wrong or manipulated, limit what a mistake can reach, and leave a record someone else can follow.