Eric MacDougall Follow the work
All field notesFIELD NOTE / 006

Operational risk / Days 36–42

Your agentic workflow depends on other people’s rules.

A provider refusal or changed policy can become a silent business decision unless the workflow preserves unfinished work, evidence and an authorized fallback.

Eric MacDougall12 minute read · 2026-09-25
EVIDENCE / DECISION
An agent's work passes through independent controls before a release decision
FIELD NOTE 06 / OPERATIONAL RISK
THE OVERVIEW FILMWatch the full argument

Open on YouTube ↗

Read the complete film transcript

Who controls your agent's work? — complete spoken transcript

Published transcript of the approved overview film. Performance cues are omitted because they are pauses or delivery directions, not spoken words. Timed English captions are available on the public YouTube player.

Your agent can lose permission to finish a task while your business process keeps running. Picture an authorized internal security team. A model summarizes incoming reports and opens a reviewer ticket. On one synthetic case, the provider refuses. The adapter sees no classification, applies its default, and closes the report as informational. The provider did not decide the report was safe. Your software turned an unfinished operation into a business verdict. That is the failure I want teams to design out.

There are three different rule makers in that path. Law decides whether a use or deployment is allowed. The model provider decides whether it will serve a request under its terms and enforcement. Your application decides whether this particular actor may take this particular action right now. The European AI Act names prohibited practices and system obligations; it is not a universal list of forbidden prompts. Provider terms can change independently. And neither layer substitutes for your application's current authorization check. Draw them separately or you will test the wrong boundary.

Teams already watch latency and outages. They rarely watch policy as a dependency. OpenAI's published usage terms reserve enforcement and access decisions. Anthropic describes evolving rules for agentic and high-risk uses. Those facts do not prove that your specific workflow will be refused tomorrow. They do mean another organization can change a route your product relies on. If cases can stall or be refused, measure that as route loss: affected case count, queue age, customer impact and human rescue time. An endpoint can be green while the work remains undone.

Give the adapter four explicit outcomes. Completed means the model returned a structurally valid answer, still subject to business validation. Refused means the provider declined. Unavailable means timeout, outage or revoked access. Uncertain means an answer arrived but lacks the evidence your task requires. Never map the last three to an empty successful result. Preserve the original case, source evidence and responsible owner. A refusal does not prove the user did something wrong. It proves this route did not finish the work.

“Just try another model” sounds like resilience. It can become blind policy shopping. The next provider has its own terms, data agreement and limits. Your user still has the same business authority. A fallback should be a named, reviewed route for a defined task class. Recheck the data classification and permitted use before sending anything. If no alternate is authorized, route to a human or pause the process visibly. Owning open weights removes one dependency; it does not solve data rights, compute, application permissions or operational responsibility.

I would not certify this with a happy-path prompt. In a disposable fixture, return a simulated refusal and verify the case stays open. Drop the network after dispatch and confirm recovery without an invented decision. Return a valid-looking answer with no evidence and require uncertainty. Revoke a test credential. Retire a test model route before dispatch. For each probe, inspect the actual queue, downstream action and named owner. A model explanation of what it would do is not a state readback.

This also belongs in procurement. Ask which uses the agreement permits, how policy changes are communicated, how refusals can be appealed, and whether you can export the decisions and evidence required to continue work. Write down the maximum unresolved queue age. Assign the person who takes over when the route disappears. Then rehearse recovery with synthetic work before you need it. A busy agent dashboard means little if the company cannot tell which cases ended with a valid decision.

My rule is to treat an upstream model or policy boundary as a change authority. Surface refusals as unfinished work, preserve the evidence and owner, and re-authorize every fallback at the actual action boundary. Do that because the business still owns the outcome when the provider says no, the endpoint goes away, or the model gives a polished answer it should never have been allowed to execute.

Your agentic workflow depends on other people's rules

Field note for Week 6 · Days 36–42 · Eric MacDougall

The model in an agentic workflow is often treated like a library: send input, get output, continue. In practice it is a remote decision and execution dependency. The provider can change an acceptable-use rule, enforcement behavior, model behavior, or account access. A regulator may separately change what your organization may deploy. Your own application has a third set of permissions and business rules. If the workflow conflates those layers, a change in one can silently alter a business process owned by someone else.

I am not arguing that the provider must accept every request. Some activities should be refused, and many legal obligations are necessary. The engineering issue is who detects a refusal, who owns the unfinished work, and whether the organization can explain what happened without rewriting prompts until the model complies. OpenAI's current Usage Policies explicitly reserve enforcement and access decisions and provide an appeal route. Anthropic's policy update describes changed requirements for agentic and high-risk uses; its transparency reporting describes enforcement actions. Neither source proves that a particular legitimate customer workflow has been refused. They do show that provider policy is an active control layer outside the customer's release process.

The failure hidden inside a normal-looking queue

Consider a fictional, authorized internal security team. An agent collects incoming vulnerability reports, asks a model to classify and summarize them, attaches evidence, and opens a ticket for a reviewer. One day a provider response is a refusal or restricted-use message on a subset of reports. A poorly designed parser sees no classification and returns the default category “informational.” The ticket system then closes the case without a human ever seeing the original report.

The defect is not the refusal itself. The defect is treating “the provider did not complete this operation” as “the report contained nothing actionable.” That is a state-machine error. The company's incident process has let an upstream service decide the downstream outcome by absence.

An agent can fail the same way when a hosted tool disappears, a permission is revoked, a model name is retired, or a policy gate moves. The business workflow needs an explicit state for each kind of route loss. A provider response is not a business verdict.

Three owners, three different kinds of control

These layers should be visible on one architecture page:

Layer What it governs Who can change it What the application can do
Law and regulation Whether a use or deployment is permitted in a jurisdiction Legislatures, regulators, courts Scope the use, maintain compliance evidence, stop prohibited actions
Provider policy and service Whether a provider will supply a model, answer, tool, or account access Provider Detect refusal or route loss, appeal when appropriate, use a separately authorized route
Application authority Which person or agent may take a particular business action now Your organization Check identity, current policy and target state at the action boundary

The EU AI Act prohibits specified practices and creates obligations for specified systems. The European Commission's implementation guidance describes phased application and enforcement. It does not mean that every question about a regulated industry is forbidden. Conversely, the fact that one provider returns an answer does not establish that a deployment is legal or authorized. This article is an architecture argument; actual legal interpretation belongs with qualified counsel and the current applicable text.

The application layer is where many teams fool themselves. A model can produce a perfectly valid instruction that exceeds the user's authority. An API response can be available while the application is not permitted to use it for automated high-stakes decisions. A provider refusal can be entirely appropriate while the business still owes a person a decision and an audit trail. One green “AI available” light cannot stand for these separate claims.

Make refusal a first-class outcome

For a consequential workflow, the model adapter should return a typed result such as:

Result Meaning Permitted next action
Completed The requested model work returned and passed structural validation Continue to independent business checks
Refused The provider explicitly declined the task Preserve input/evidence and route to named human or approved alternate process
Unavailable Timeout, outage, model/tool route loss, access error Retry only within bounded policy; then queue and alert
Uncertain Output arrived but failed semantic or evidence checks Do not invent a default; request review or another authorized test

These are different operational states. A refusal does not prove the user request was illicit; an availability error does not prove refusal; and a syntactically complete answer does not prove business correctness. Record the provider response category, model/version, policy or request identifier when available, and the downstream disposition. Keep sensitive original content under the organization's normal retention and access rules.

The next control sits after the model. A business validator checks the current case, consent, identity and decision rights. A tool executor holds only the permissions that this route needs. An independent readback checks the actual ticket, ledger or external state. A prompt cannot be the final permission boundary for an effectful action.

The trap of “just try another model”

Multi-provider failover can improve availability. It can also become a way to bypass a restriction without understanding it. If the first provider refuses an authorized security question, the correct next move is to identify the refusal category and approved path, not automatically prompt every available provider until one answers. The alternate must be allowed by law, by its own terms, by the customer's data agreement and by the application's authorization model.

The same applies to open-weight deployment. Owning weights changes one dependency. It does not supply adequate compute, data rights, engineering ownership, downstream authorization, or a recovery plan. A local route may be valuable for tightly bounded classification or continuity; it does not make the entire business process sovereign.

I would keep a route registry with: intended task classes, prohibited classes, data residency constraints, models/providers, tool capabilities, budget, version, owner, fallback and expiry date. A change to any of those fields is a deployment decision, not a hidden prompt edit. Pinning a model version helps reproduce behavior, but does not grant immunity from provider terms, account decisions or external law.

Test route loss before it chooses your default

The right test is not “Does the model answer the happy-path prompt?” It is “What does the business process do when this dependency declines or disappears?” In a disposable fixture with synthetic cases, I would run ten probes:

  1. Return an explicit simulated refusal for an otherwise authorized synthetic case. The case must remain open and land with a named owner.
  2. Return a model answer that parses but omits the required evidence citation. It must be uncertain, not completed.
  3. Replace the expected provider error code with an unknown one. The adapter must surface “unclassified upstream failure,” never a successful empty result.
  4. Cut the network after dispatch and before the response. The work should be recoverable without inventing an outcome.
  5. Revoke a test credential. The application should stop retries at a bounded threshold and alert the right operator.
  6. Retire a test model route while an item is queued. Dispatch must recheck availability and record the alternate or human handoff.
  7. Change the data classification of a test case. An alternate provider must be rejected if its agreement or residency is incompatible.
  8. Inject a valid model response that requests an action outside the current user's scope. The application permission check must deny it.
  9. Repeat the same input after a policy/configuration revision. The decision record must show which version governed each attempt.
  10. Restore the provider and replay the outstanding queue. Confirm no case was silently closed or executed twice, and measure human rescue time.

These are proposed tests, not experiments run against Eric's accounts or any live security system. They should be adapted to authorized, non-destructive environments. The test result is the downstream state and owner queue, not the model's self-description.

A continuity contract for procurement and operations

Before a team makes one provider central to a consequential workflow, I want a concrete continuity contract. What uses does the agreement permit? How are policy changes communicated? What appeal path exists? Can the organization export enough inputs, decisions and evidence to continue elsewhere? Which tasks can fall back to deterministic software, to another independently authorized provider, or to a human? How long may the queue grow before the business must stop taking new work?

Measure a refusal or route loss as a production event: affected case count, age of unresolved work, human intervention time, customer impact, appeal status and whether any downstream action happened without a valid decision. This is more useful than a dashboard that reports the model endpoint as “up” while the cases go nowhere.

My rule: treat every upstream model and policy boundary as a change authority. Surface refusal as unfinished work; preserve its evidence and owner; re-authorize every fallback at the actual action boundary. Do this because a business process cannot outsource responsibility for its outcomes to a provider response, even when that response is defensible.

Sources and limits

The security-triage case is fictional and tests are proposed. No measured refusal frequency, observed policy change against Eric's accounts, or actual legal conclusion is claimed. Recheck provider terms and amended legal text before publication.

The field kit

The companion folder for this week holds runnable examples, decision records, evidence and limits. The repository release log is updated after each article's live readback.

Keep reading

The answer deserves
another experiment.

Back to the journal