Construct the Task World

Vocabulary for this episode

Episode 01's glossary still applies. Six additions, plus two terms this series coins and one naming collision worth resolving before it confuses you.

Two terms this series coins, because no standard word exists and the concepts carry real weight downstream:

Freshness budget — the maximum age at which a piece of data is still valid for the specific decision it supports. Not how often it refreshes. How stale it can get before the decision it feeds becomes wrong.

Run attestation — the automatic record of what the world actually was for one specific run. The manifest says what should be true. The attestation records what was true. You need both.

One naming collision. OpenAI uses the word manifest for a narrower thing: the starting contents of a fresh sandbox workspace — which files, repositories, and mounts are placed there before the agent begins. Their own documentation is careful to say this is not the source of truth for every running sandbox, because a live run may instead start from reused state or a snapshot.

This series' Environment Manifest includes that workspace contract and adds the assumptions a business decision depends on: which data, at what freshness, under which policy version, against what clock, reachable through which services, with what behavior on resume.

OpenAI's manifest specifies what a fresh workspace contains. The Environment Manifest specifies what must be true for the agent's decision to be trustworthy.

Both are useful. They operate at different altitudes, and a technically informed reader will notice if you blur them.

Who this episode is for, and what you will own

This is the episode where the division of labor is least intuitive, because almost everything in it looks like infrastructure. Most of it is not.

Every item in the right column is a statement about when a business decision stops being valid. Engineering cannot infer any of them from a prototype, because in a prototype the data is always fresh, the policy is always current, and the scope is always complete.

Engineering builds the world. You specify what must be true inside it.

Where this sits in the series

• Episode 01Bounds what one run may cause
• Episode 02 — this oneDefines the conditions under which its decisions can be trusted
• Episode 03Establishes whose authority it carries
• Episode 04States what still holds under attack
• Episode 05Proves all four remain true in production

The coupling to Episode 01 is direct and worth stating precisely, because the two artifacts are easy to confuse:

The envelope says the run may reach the CRM. The manifest says which CRM, holding which data, how current, reachable how, and what happens when the connection dies halfway through.

The envelope bounds the world. The manifest constructs it.

Two mechanisms from Episode 01 get used here as machinery rather than as ideas. The consequence classes become a runtime control — a run that cannot verify its data drops from C3 to C2 and keeps working at lower authority. And the irreversible step determines what a failed run is legally allowed to do next.10

01The staging paradox

Every team building agents eventually hits the same wall, and it arrives on roughly the same schedule.

The agent works in staging. Consistently. Dozens of cases, clean results, the demo goes well. The team ships it. Within a week, production produces behavior nobody can reproduce.

The investigation follows a predictable arc. Model version — unchanged. Prompt — identical. Tool definitions — same. Re-run the failing case in staging — passes.

At which point the team reaches for the least useful explanation available: the model is non-deterministic.

Sometimes that is true. Far more often, something else happened. The two environments were not the same world, and nobody had ever written down what "the same world" would mean.

The differences are never dramatic. That is what makes them survive:

• Staging carried version 2.7 of the payment client. Production has 2.8, which changed one field's meaning
• Staging's customer records were a six-week-old snapshot — clean, complete, well-formed. Production's records contain half-finished migrations, legacy field formats, and account states no test fixture ever modeled
• Staging reached an internal service directly. Production routes through a proxy that strips a header
• Staging's container defaulted to UTC. The business runs on IST

Each difference is individually trivial. Together they constitute a different world, and the agent reasoned coherently about the world it was actually in.

That word is chosen carefully. The agent did not reason correctly — its conclusion was wrong. It reasoned coherently — its inference was sound given its inputs. This is exactly why the failure is so hard to catch. There is no defect in the chain to find. The reasoning trace reads well. The output is well-formed. The error entered before the first token was generated.

The fix nobody writes down

The diagnosis above is common. The remedy is not, so here it is concretely.

Do not try to make staging identical to production. That is expensive, usually impossible, and often unsafe — Episode 07 covers why a production-realistic test environment carries production-realistic blast radius.

Do this instead: make the difference visible and bounded.

1. Declare the dimensions that must match, and the dimensions that are allowed to differ. Runtime and policy version must match. Customer data will not, and should not
2. Emit a run attestation in both environments recording the same fields — image digest, policy version, schema versions, data freshness, network mode, clock
3. Diff the two attestations as a release step. Any difference in a must-match dimension blocks the release
4. Where a difference is intentional, record it as a known variance with a reason

This converts "it worked in staging" from a hopeful claim into a checkable one. It is a small amount of engineering work and it eliminates the single most expensive category of agent debugging.

The rest of this episode specifies what belongs in that declaration.

02Three things the word "environment" is doing

The word environment is overloaded to the point of uselessness. In a single meeting it can mean infrastructure configuration, a running container, a mounted workspace, a view of data, a policy bundle, a network boundary, and an active session.

Three distinct objects hide inside it, and confusing them is the source of most of the confusion in this space.

The third row is where teams get stuck. A running instance can be inspected while it exists and logged after it ends. It cannot be approved in advance, because it does not exist until the run begins.

A running instance can be inspected. Only a specification can be approved before the run exists.

This is why the manifest matters. It is the reviewable object. It is the thing a governance board, a security reviewer, or an auditor can actually look at.

The major platforms converged on this same split independently, which is a reasonable signal that it is real rather than merely tidy. Anthropic separates a reusable environment configuration — which determines where and how sessions run — from the session, which is the per-task running instance provisioned from it. OpenAI describes the instance from the execution side: an isolated Unix-like environment with a filesystem, shell, installed packages, mounted data, and snapshots.

Two platforms with no incentive to agree, both declining to treat the world as an incidental byproduct of running an agent.12

03Four dimensions of a world

A world given to an agent has four dimensions. As with Episode 01's four dimensions of consequence, independent is the operative word — each can be correct while the others are wrong, and no single control covers more than one.

• RuntimeWhat the agent can execute
• InputsWhat the agent can know, and when it was true
• ConnectivityWhat the agent can reach
• LifecycleHow the world begins, resumes, and ends

Here is the imbalance that produces most agent failures:

Conventional infrastructure tooling covers the first dimension extremely well and the second almost not at all.

A container specification can pin every dependency by cryptographic digest, verify every checksum, and reproduce byte-for-byte — while the agent inside it operates on a nine-day-old customer snapshot, under a policy bundle that expired last quarter, against a clock in the wrong timezone.

The build is perfectly reproducible. The world is wrong.

That gap is where agent failures live, and it is almost entirely product territory, because only product knows which decisions break when which data goes stale.

04Runtime — what the agent can execute

This dimension is short, because the discipline already exists in mature software supply chains and your engineering team almost certainly has it. Three rules cover it.

Pin everything. Base images by cryptographic digest rather than by tag, because a tag can be repointed at completely different content without any change to the code that references it. Application dependencies via lockfiles with checksum verification. System packages by version. Unpinned tags are treated as a supply-chain vulnerability in their own right, precisely because the contents can change while the description does not.3

Declare every capability. Not just what is required — what is present. These are different lists, and the gap between them is the interesting part.

Decide whether the agent may modify its own runtime. This is a product decision disguised as a configuration flag, and section 05 is about it.

The second-order effect

None of the above is new. What is new is what happens once an agent occupies the container rather than a conventional service.

For an ordinary service, a drifted dependency produces a crash or a type error. For an agent, a drifted dependency produces a different set of available actions. An agent exploring its own filesystem will find whatever is there and reason about how to use it.

Every executable available to an agent expands the set of actions it can attempt, whether or not the workflow intended to expose it.

The word executable is deliberate. A parsing library is not meaningfully a capability. A shell, a language interpreter, a browser, an HTTP client, a cloud command-line tool, or a database client absolutely is. Those are the things a manifest review should focus on.

The practical test: for each executable present in the environment, name the workflow step that requires it. Anything unattributable is a candidate for removal — not because it is dangerous today, but because it expands reach without appearing in any reach decision anyone made.

This is Episode 01's "capability that does not exist" principle, applied one layer down.

05Runtime — may the agent modify itself?

Can the agent install software while it is running?

Anthropic exposes this as an explicit setting. In limited networking mode,

allow_package_managers controls whether the agent can reach public software registries like PyPI and npm beyond the hosts on its allowlist. It defaults to false.4

That boolean is more consequential than it looks.

Setting it true means the contents of the environment are no longer determined by the manifest. The agent extends its own capability surface mid-run, from a public source, based on its own judgment about what it needs. Nothing in your specification describes the world the agent ends up in.

Whether that is acceptable depends entirely on the workload:

The point is not that self-modification is wrong. It is that it should be a recorded decision with a stated reason and a named owner — not a default inherited from whichever tutorial the prototype was built from.

The question to ask: "Can the agent install software mid-run, and which workflow step requires that?" If nobody can answer the second half, the answer to the first half should be no.

06Inputs — the dimension nothing else covers

This is where the expensive failures live, because they are the least visible.

Every input has two properties: content and time. Most teams specify the first and assume the second.

Three things can go wrong, and they are genuinely different problems requiring different fixes.

Authority — is this the real source, or a convenient copy?

A test fixture that was accurate when someone wrote it may no longer reflect how production represents the same entity. Migrations change what fields mean. Legacy records carry formats that current code paths never produce. A cached view can be perfectly authoritative for reads and dangerously stale for decisions.

The question: for each input, is this the system of record, or something downstream of it? If downstream, how far, and does that matter for this decision?

Completeness — does the agent see everything, or a slice?

This one is subtle, because a filtered view is usually correct policy. The refund agent is deliberately scoped to one customer. That is a reach decision from Episode 01, not a defect.

The danger arrives when the agent cannot distinguish "this data does not exist" from "this data exists but is outside what I can see."

Here is the failure in full:

The agent queries for prior refunds on this account. A permission rule suppresses two records belonging to a linked account. The query returns an empty list. The agent concludes there were no prior refunds. It issues a duplicate refund.

The security control worked perfectly. The business outcome is a duplicate refund on a customer who has already been refunded twice.

A scope boundary that is invisible to the agent becomes a factual claim the agent will act on.

The fix is not to widen the scope. It is to make the boundary visible in the result.

An empty result can mean at least five completely different things:

1. No matching record exists
2. Records exist but are outside authorized scope
3. The source was unavailable
4. The query completed only partially
5. Freshness could not be verified

An agent that receives an empty list for all five will treat all five as the first. So tools must return their epistemic status alongside their data — plain English: the tool must say what it knows about its own answer, not just give the answer.

TOOL RESULT
  status:    partial
  scope:     requesting_customer_only
  freshness: 2026-08-01T08:11:00+05:30
  records:   []

This is a small engineering change with a large effect. It converts a silent, unfalsifiable assumption into an explicit input the agent can reason about and a reviewer can audit afterward.

What you own here: deciding that this distinction matters for your product, and which boundaries must be surfaced. Engineering decides the format.

Freshness — how old is it, and does the age matter?

Most teams can say where data comes from. Very few can state the maximum age at which it remains valid — which is the decision that actually matters.

A freshness budget is the maximum age at which an input remains valid for the decision it supports.

The third column is the whole exercise. For each input, finish the sentence: if this is N old, the agent may incorrectly ______. If the blank cannot be filled, the input may not belong in the world at all.

The budget is derived from the decision, not from how easily the data refreshes. Engineering can build any refresh cadence you ask for. Only product knows which decisions break when the data is stale.

07How to find a freshness budget nobody knows

The table above assumes someone can state these numbers. Frequently nobody can, because in the human process the question never came up — a person looking at a screen implicitly saw whatever was there.

Four methods, in descending order of strength.

1. Work backward from the failure. Ask the domain owner: "Has anyone ever made a wrong decision here because they were looking at old information? What happened?" Incident memory is more reliable than estimates. One real story usually produces a defensible number.

2. Find the underlying change rate. How often does this data actually change for a typical case? If a subscription record changes twice a year, a five-minute budget is theater. If billing events arrive continuously, anything but real-time is a guess. The budget should be tighter than the change rate, not tighter than your comfort.

3. Use the decision boundary. If the decision turns on whether something happened within a window — a thirty-day eligibility period, a settlement cutoff — the budget is bounded by how close to that boundary a case can sit. Data that is one day old is harmless in the middle of a window and decisive at its edge.

4. Start real-time and relax with evidence. Where the cost is acceptable, require current data initially and log how often a cached read would have differed. After a few weeks you have measured the budget instead of guessing it.

Whichever you use, record the method in the manifest alongside the number. A freshness budget with a stated derivation is an auditable decision. One without is a number that will be quietly relaxed the first time it causes latency.

08Retrieved knowledge is an input too

Most agent products retrieve documents — knowledge base articles, policy pages, past case notes, product documentation — and inject them into the model's context. This is usually called retrieval and treated as a separate concern from "data."

It is not separate. A retrieved document is an input with exactly the same three properties, and it typically has none of them specified.

Three failure modes follow, and none of them raise an error.

Stale index. The source article was updated on Monday. The search index rebuilds weekly. Until Friday, the agent confidently applies last month's policy. Nothing is broken. The index is doing exactly what it was configured to do.

Silent retrieval failure. The retriever returns three documents of low relevance rather than returning nothing. The agent, which has no way to evaluate retrieval quality, treats them as relevant and reasons from them. This is the empty-versus-suppressed problem in a different costume: the agent cannot distinguish "here is what you asked for" from "here is the closest thing I found."

Superseded content that was never removed. Old policy pages, deprecated procedures, and draft documents live in the same index as current ones. Retrieval ranks by similarity, not by authority. The superseded document often reads more relevant, because it was written about exactly this situation.

What the manifest must specify

The one rule that matters most, and it connects forward to Episode 04: retrieved content is semi-trusted. It can inform what the agent knows. It must never be the source of a consequential parameter. The amount to refund comes from the payment ledger, never from a document that describes a refund.

What you own: which corpus is authoritative, how far behind it may be, and what the agent must be told about the quality of what it got back.

09The model, prompt, and tool schema are part of the world

Here is a blind spot that survives in almost every environment specification.

Teams pin the container image with great care and then change the model version, the prompt template, the tool schema, or the policy bundle without treating any of it as an environment change.

But from the agent's perspective these are not incidental. They are the world:

• The model versiondetermines how the same inputs get interpreted
• The prompt templatedetermines what the agent believes its job is
• The tool schemadetermines what operations appear to exist and what their parameters mean
• The policy bundledetermines which rules apply
• The retrieval corpus versiondetermines what knowledge is reachable

Change any one of these and the agent is operating in a different world, even though the container image is byte-identical.

Episode 05 calls the resulting failure substrate drift — quality moves and nobody can attribute it, because the thing that changed was never versioned as part of the environment.11

The manifest fix is small and worth doing immediately:

Every one of these goes into the run attestation. Without them, "quality dropped last Tuesday" is an observation you cannot act on. With them, it is a query.

A caution worth stating: pinning the model version is necessary and not sufficient. Providers can change serving infrastructure, safety filtering, and default parameters behind a stable version string. The manifest should record what you pinned; the attestation should record what actually responded, including any version metadata the provider returns.

10Policy is a versioned dependency

One category of input deserves separate treatment because teams consistently miss it, and because the miss is silent.

Business policy — refund ceilings, eligibility rules, escalation thresholds — usually enters the agent's world as text. A document. A knowledge base article. A retrieved chunk. A section of the system prompt.

That text is a versioned artifact whether or not anyone versions it.

When the refund policy changes, every running world still carrying the old text is producing decisions against superseded rules. Nothing in the system reports an error, because from the software's point of view nothing is wrong. A document was loaded. The document was read. A decision was made.

There is a sharper point here that connects straight back to Episode 01's structural-versus-behavioral distinction.

Policy delivered as context is a behavioral control. It shapes what the agent decides. It does not constrain what the agent can do.

Policy in context tells the agent what the limit is. Policy in the credential makes the limit true.

The second case is not only safer — it is observable. Episode 04 makes the point that structural denials are your best detection signal. A behavioral control that goes stale produces no signal at all.

The manifest should record which one you have, per policy rule. Where a rule exists only as text, that is a finding, not a configuration detail.

11Time is an input, even when nobody passes it

Agents reason about time constantly and almost always implicitly.

Recent charges. Current subscription. This billing cycle. Overdue invoice. Expired warranty. Within the eligibility window.

Every one of those phrases resolves against a clock the agent did not set and nobody specified.

Three temporal facts belong in the manifest.

System time and timezone. A container defaulting to UTC while the business runs on IST produces off-by-one-day errors at every date boundary — a five-and-a- half hour offset that silently reclassifies any event near midnight. For a thirty-day refund eligibility window, that is a financial decision made wrongly by a configuration default nobody chose.

Effective date. What the agent should treat as now for business purposes. Usually this equals system time. It diverges in two cases that matter:

• Backdated processinga run must evaluate a request as of its submission date, not today
• Evaluationa run must be pinned to a fixed date to be reproducible

Business calendar. Settlement cutoffs, fiscal periods, holiday schedules. A refund submitted after the 18:00 IST cutoff settles the next business day, and the agent cannot possibly know that unless the world tells it.

The evaluation consequence

This one is worth stating plainly because it invalidates test suites quietly.

A test suite that runs against the current system clock is not reproducible.

The same case passes in one week and fails in another, because the relationship between the fixture and now silently changed. A dispute filed twenty-eight days ago is inside a thirty-day window today and outside it next week. Nothing in the test changed. The calendar did.

Pinning the effective date is the difference between an evaluation that measures the agent and an evaluation that measures the calendar.

12Connectivity — what the agent can reach

Connectivity is where the manifest and the Consequence Envelope meet most directly. Episode 01 made reach a decision. The manifest turns that decision into configuration.

Record it as three lists, not one — the same structure as Episode 01, now with implementation attached:

The middle row is where drift accumulates. Nothing in a permitted-but-unnecessary destination is wrong on the day it is added. It becomes wrong six months later, when nobody remembers why it was added and the workflow it served no longer exists.

Unattributed reach is environmental drift. The manifest should make every external dependency traceable to a task step.

On defaults, stated precisely

It is tempting to write that the industry has converged on default-deny networking. The evidence does not fully support that, and the inconvenient detail teaches something more useful than the tidy version.

Anthropic offers two modes. unrestricted permits broad outbound access with a small blocklist. limited blocks by default and permits only hosts named in an allowlist, with separate toggles for package managers and MCP servers, both defaulting to false.4

But the default depends on how the environment was created. API-created environments default to unrestricted networking. Sandboxes provisioned through Claude Studio default to limited.

So the accurate statement separates default from recommendation:

Anthropic's API-created environments default to unrestricted networking, while its production guidance recommends limited with an explicit allowlist.

That framing is more credible than flattening the evidence, and it produces a better instruction for the reader: check what your creation path actually does, because two paths on the same platform may not agree.5

OWASP's guidance on excessive agency points the same direction from the security side — minimize the extensions an agent may call, prefer granular extensions over open-ended ones such as arbitrary URL fetching, and limit downstream permissions to the minimum necessary.6

MCP servers are not simply endpoints

An MCP server — a standardized connector that exposes capabilities to an agent — is not merely a data endpoint. It may expose resources, prompts, or executable tools, and its capability surface can change without any change to your manifest.

Anthropic treats MCP access as a distinct networking permission, separate from ordinary allowed hosts, defaulting to false.

The manifest should therefore record both the server and the specific capabilities the agent may use through it — not merely that the connection is permitted. "We allow this MCP server" is a statement whose meaning can change next week without anyone telling you.

How connectivity stays bounded when execution is compromised is Episode 04. This episode only declares what must be reachable.

13Lifecycle — how the world begins, resumes, and ends

The fourth dimension, and the one with the most product decisions hiding in it.

Beginning

Does each run start fresh, or can it inherit?

Anthropic provisions a sandbox according to the referenced environment configuration when a session starts, which makes the specified world the starting point and inheritance an explicit choice.

The alternative — warm pools of reused instances kept ready to reduce startup latency — is a real cost optimization and a real correctness risk.

A reused instance is an inherited starting condition wearing a different name.

What you own: whether the latency saving is worth the possibility that this run begins in a world the previous run modified. For most C3 workflows it is not.

Resuming — two mechanisms that look identical and are not

Here two things both look like "saving the world" and are meaningfully different.

OpenAI's Agents SDK provides snapshotting and rehydration — restoring agent state in a fresh container to continue from the last checkpoint if the original environment fails or expires. Separately, its sandbox documentation distinguishes a manifest, which seeds a fresh workspace, from a snapshot, which seeds a new session from previously saved contents. Anthropic checkpoints an idle session and preserves its filesystem and installed packages for later resumption.78

The product question underneath is singular:

When a run resumes, does it enter the world the manifest describes, or the world the previous attempt left behind?

Both are legitimate. A four-hour task that loses its workspace on every transient network failure is unusable. But resumption inherits everything — including the partial writes, cached responses, and half-completed operations that may have caused the failure in the first place.

So the manifest specifies three lists:

The third list is the coupling point with Episode 01, and it is the one teams skip.

A run that resumes after submitting a payment must not assume the payment did not happen. It is in exactly the three-way ambiguity Episode 01 described: the call never arrived, the call failed, or the call succeeded and the confirmation was lost. Retrying is safe only when the downstream operation is idempotent.9

The starting condition of a resumed run includes the uncertain state of the outside world, and the manifest records that this must be reconciled rather than retried.

Ending

What triggers teardown, what is preserved, what is verified as gone?

Audit records and decision evidence must survive. Credentials, workspace contents, and cached external data generally must not.

"The container is destroyed" is an assumption about the platform, not a specification for your product. The manifest should name what must not survive and how its removal is enforced — including the category teams always forget: sessions the agent opened in other systems, which do not close because your container did.

Duration, and how it interacts with freshness

Maximum run lifetime interacts with every other dimension, and this is the failure mode that arrives with long-running agents.

Freshness is validated when the world is created and consumed throughout the run. The longer the run, the wider the gap between what the agent knows and what is true.

For a ten-minute run, the gap is negligible. For a four-hour run acting on account balances read at minute one, it is not.

The manifest should specify which inputs must be re-read rather than cached, and at what interval. This is the same wall-clock bound Episode 01 set as a cost and containment control, now doing a third job as a correctness control.

Failure

What happens when the world itself dies mid-run?

The available answers — resume from checkpoint, restart clean, escalate, mark indeterminate — have very different consequences depending on what the run had already done to the outside world.

The irreversible step identified in the Consequence Envelope determines the legal failure behavior in the manifest.

Before that step, clean restart is safe. After it, restart is a duplicate action.

The full state contract — durable memory across runs, cross-run contamination, what survives session completion — is a later concern. This episode specifies only starting state and resume obligations.

14Validate before starting — and count the cost

Here is the gap in most environment specifications, and it is the same gap Episode 01 identified in its own artifact.

A manifest that lists requirements but cannot block a run is documentation. It describes an intention nobody enforces.

Three validation outcomes:

Applied to the refund agent:

Degraded mode is the interesting row

The second row is where this becomes a genuinely good product mechanism rather than a safety tax.

Degraded mode is not failure. It is the run continuing at a lower consequence class.

The agent that cannot verify data freshness drops from C3 Act to C2 Propose. It still reads the case. It still investigates. It still produces a recommendation a human can act on. It simply does not produce irreversible effects on data it cannot vouch for.

The customer still gets progress. The business still gets value. Nothing irreversible happens on unverified inputs.

That mapping turns Episode 01's classification from a design-time label into a runtime control — which is exactly why the classes needed names in Episode 01.

Now count what refusal costs

This is the mirror of Episode 01's "the envelope can also be too tight," and it is missing from most manifests.

Every row in that table sends work somewhere. Six refuse-to-start conditions with no capacity conversation is not a safety design — it is an unplanned load transfer.

If a refusal condition fires more often than the receiving team can absorb, you have two choices and both are product decisions: fix the dependency so it fires less, or accept a wider bound with a compensating control. Silently leaving it is choosing to degrade the product while the dashboard stays green.

A manifest that cannot block startup is documentation. A manifest that blocks startup without a capacity plan is a queue you did not budget for.

15The manifest is the contract; the attestation is the receipt

A manifest states what should be true. It cannot, by itself, establish what was true for one particular run.

That second thing is what an incident review needs, and what an auditor asks for first.

So the manifest has a companion. The run attestation is captured automatically, per run, and stored with the audit evidence.

This is not a separate deliverable. It is a section of the manifest — the list of fields the platform must emit so that the specification becomes verifiable rather than aspirational.

It also resolves an overclaim that appears in a lot of agent documentation. Without attestation, "this environment is reproducible" is an assertion. With it, reproducibility becomes a property you can check after the fact, per run.

And it is what Episode 05's evidence register is built on. Every operating claim in that episode requires attestation fields to exist. If they are not emitted here, that episode has nothing to work with.

16Translating this to your product

The refund agent makes freshness legible because money makes staleness expensive. The same four dimensions apply everywhere.

The generalizable questions, whatever you build:

1. Which input, if stale, produces a confident wrong answer rather than an error?
2. Where can the agent mistake "you cannot see it" for "it does not exist"?
3. Which business rule exists only as text somewhere?
4. What does the agent think "now" means, and who set that?
5. If this run resumes after a failure, what must it re-verify before continuing?

17The artifact

18How to run the review

Sixty to ninety minutes, with product, engineering, security, and the owner of each data source. The data-source owners are the ones teams forget to invite and the ones who answer the hardest questions.

Minutes 0–10 · Frame it. State the argument: an agent adapts to a wrong environment instead of crashing. The goal is to write down what "right" means.

Minutes 10–20 · Runtime. Is every executable attributable to a workflow step? Is the image pinned by digest? May the agent install software mid-run, and why?

Minutes 20–45 · Inputs. This is the bulk of the meeting. For each input: what is the freshness budget, how was it derived, and what breaks beyond it? Is any business rule delivered only as text? Can the agent distinguish empty from suppressed? What does the agent treat as "now"?

Minutes 45–55 · Connectivity. Walk the three lists. For every permitted entry, ask why. Are MCP capabilities recorded, not just MCP access?

Minutes 55–70 · Lifecycle. Is each run fresh? What is restored, discarded, and re-verified on resume? Which inputs go stale within the maximum duration? What happens if the world dies before the irreversible step, and after it?

Minutes 70–80 · Validation and cost. Which conditions refuse startup? Which trigger degraded mode? Does degraded mode map cleanly to a lower consequence class? For each refusal, who absorbs the work?

Minutes 80–90 · Attestation. Can you reconstruct, six months from now, which world a specific run occupied? Walk the field list and find what is missing.

Leave with: a completed input table with derivations, a named degraded mode, a refusal-cost owner for each condition, and the list of attestation fields engineering must add.

19Anti-patterns

• "It's the same container as staging."Same image, different world. Data, policy version, network path, substrate versions, and clock all live outside the image.
• "We pinned the dependencies."Necessary and insufficient. That covers one dimension of four.
• "The agent can install what it needs."Legitimate for some workloads, and a capability surface the manifest no longer bounds. Record it as a decision.
• "The data is live."Live at which moment? A four-hour run reads live data at minute one and acts on it at minute two hundred.
• "Policy is in the system prompt."Then policy is a behavioral control that can go stale silently, and produces no denial signal when it does.
• "We pinned the model version."Providers change serving behavior behind stable version strings. Record what actually responded.
• "Retrieval is a separate concern."A retrieved document is an input with authority, completeness, and freshness properties. It just has none of them specified.
• "The query returned nothing, so there's nothing."Five different situations produce an empty list, and the agent will treat all five as the first.
• "The container is destroyed afterward."That covers the workspace. Not external session state, not cached credentials in a connected service, not data written to mounted storage.
• "We have a manifest."Does it block startup when violated? If not, it is a description of intent.
• "We refuse to start if anything is unverified."Then measure how often that fires and ask who is absorbing it.

20What product owns

Engineering builds the world. Six decisions inside it cannot be inferred from a prototype, and none require infrastructure expertise.

1. Freshness budgets. The maximum age at which each input remains valid, derived from the decision it supports — with the derivation method recorded.
2. Policy versioning. Which version is authoritative, when it takes effect, how running worlds learn it changed, and whether it is enforced structurally or only stated as text.
3. Scope semantics. What the agent must be told it cannot see, so that boundaries do not silently become false facts.
4. Knowledge authority. Which corpus is authoritative, how far behind it may run, and what outranks what when sources conflict.
5. Degraded modes. What the run may still do when a requirement cannot be verified, expressed as a consequence class from Episode 01.
6. Resume obligations. What a resumed run may assume about the outside world, and what it must re-verify before continuing.

Engineering can implement any of these. None of them can be inferred from a prototype, because in a prototype the data is always fresh and the scope is always complete.

21The AI PM page

Field artifact · Episode 02 · print this

Before your team builds the world

How to use this. The Environment Manifest is what your team produces together. This page is what you bring to the room. Block 2 is the meeting — if those questions go unanswered, the manifest will describe a container rather than a world.

1 · Decisions you own

2 · Questions you must get answered

1. For each input: if this is a day old, what does the agent get wrong? If the sentence cannot be finished, the input may not belong in the world.
2. Which of our business rules exist only as text? Those can go stale silently and produce no denial signal.
3. Can the agent tell "nothing exists" from "you cannot see it"? If not, every permission boundary is a potential false fact.
4. What does the agent think "now" is, and who set that? Check the container timezone before you check anything else.
5. How far behind the source can our knowledge base be, and are retired documents actually removed from the index?
6. Are the model, prompt, and tool schema versions recorded per run? Without them, "quality dropped last week" is unanswerable.
7. If the run fails after the irreversible step, what does it do? Restart is the wrong answer.
8. Which conditions refuse startup, and who picks up that work? Count it at forecast volume.
9. Six months from now, can we reconstruct which world a specific run was in? If not, no incident review will conclude anything.

3 · Assumptions to test

• That the same container image means the same world.
• That "the data is live" means live at the moment of the decision.
• That a filtered view is visible to the agent as a filtered view.
• That the policy the agent is reading is the policy currently in force.
• That the retrieval index reflects what was published this week.
• That pinning the model version pins the model's behavior.
• That "the container is destroyed" covers sessions opened in other systems.
• That a resumed run knows whether its previous payment went through.
• That degraded mode was designed rather than defaulting to failure.
• That the escalation queue can absorb every refuse-to-start condition.

4 · Conversations to schedule

5 · Signals this work was skipped

• The team explains a production failure as "the model is non-deterministic."
• No input has a stated maximum age.
• The refund ceiling exists only in the system prompt.
• Nobody can say when the knowledge base was last reindexed.
• Model and prompt versions are not recorded per run.
• An empty tool result and a suppressed tool result look identical.
• The container timezone has never been checked.
• Resume behavior after the irreversible step is undefined.
• There is a manifest, and it cannot block a run.
• Degraded mode is not defined, so every unmet requirement is a hard stop.
• Nobody has counted how often those hard stops fire.

The test

If you can answer block 2, the manifest is a ninety-minute conversation with the right people in the room.

If four or more are unanswered, your agent is already operating in a world nobody specified — and it will keep adapting to that world, coherently and confidently, until something expensive happens.

22The line

A traditional application fails loudly when its environment is wrong. An agent adapts to it.

A scope boundary invisible to the agent becomes a factual claim the agent will act on.

Policy in context tells the agent what the limit is. Policy in the credential makes the limit true.

The manifest is the contract. The run attestation is the receipt.

→Next · Give the Agent an Identity

The manifest now specifies which CRM, which payment endpoint, which policy version, which knowledge corpus, and which slice of customer data the run receives.

One question remains, and it is the one an auditor asks first.

Who enters that world?

A connection may be scoped to a single customer and a single refund operation, but the action still carries an identity. That identity determines whose authority is being exercised, when it expires, what the target system records in its logs, and whether the action can be traced back to the human who set it in motion.

A refund appears in the ledger. ₹1,847. The actor field reads svc-support-automation. That value identifies a technical caller. It does not explain the action — not who was affected, not who initiated it, not under whose policy it was permitted, and if ten agents share that account, not even which agent acted.

Episode 02 specified the world. Episode 03 specifies the actor inside it.

You now hold Artifact 02 — the Environment Manifest: runtime, inputs, connectivity, lifecycle, substrate versions, validation with refusal costs, and run attestation for one agent workload.

The next question Who is acting inside that world, on whose authority, and for how long?

Continue · Environment 03 — Give the Agent an Identity · artifact: the Authority Matrix.

Back one step · Environment 01 — Begin With Consequence · the bounds this world operates under.