It’s a Thursday afternoon and you’re staring at a trace log. An agent your team shipped six weeks ago has just completed a task chain: it read a support ticket, pulled a customer record, called a scoring model, drafted a decision, and sent an email. Twelve tool calls, four model invocations, one outbound action with legal consequences. The trace is clean. Every step succeeded.
Then someone from legal asks a question you cannot answer: which jurisdiction’s rules governed step seven?
You don’t know. The user was in one state, your inference endpoint in another, the scoring model was fine-tuned by a vendor headquartered somewhere else, and the retrieval index pulled a document written under a fourth set of assumptions. The agent had no concept of any of this. It had a system prompt, a toolset, and a goal.
Twenty-nine answers to the same question
By most current counts, roughly 29 states have moved on AI rules while no federal statute governs the field. That number gets cited as a political fact, and it is one. But for anyone building agent systems, it’s an engineering fact first.
A single federal rule, even a strict one, is a constraint you can compile against. You encode it once, test it once, and audit it once. Twenty-nine partially overlapping regimes are something else entirely. They are a distributed consistency problem where the nodes disagree, the schema keeps changing, and there is no leader election.
Most agent frameworks today have no vocabulary for this. We have tool schemas, memory stores, planners, and evaluation harnesses. We do not have a first-class notion of applicable law as runtime context. Jurisdiction is not a variable the planner reasons over. It sits in a policy document written by humans, enforced by other humans, several layers above the loop that actually takes action.
Where the mismatch actually bites
The speed argument gets made badly. People say models move faster than rules, as if the problem were legislative calendars. The deeper issue is structural: laws are written about decisions, and agents don’t make decisions in units that map onto them.
Consider what a rule usually wants to know:
- Who made the determination, and can it be explained to the affected person?
- Was a human meaningfully involved, and at what point?
- What data entered the determination, and was its use disclosed?
- Can the outcome be contested, and against what record?
Now consider what an agent trace gives you: a sequence of token-level generations, tool calls with partially logged arguments, retrieved context that may not be reproducible next week, and a final action whose causal lineage is probabilistic rather than deterministic. The units don’t line up. A regulator asks for the decision. You have a distribution over trajectories.
This is why compliance retrofits fail so often. Teams bolt a logging layer onto a finished agent and discover the log answers questions nobody is asking.
Three fights that are really one fight
The current policy debate splits into camps that look unrelated. Carnegie has written about a compute coalition among free-world democracies, treating AI governance as a question of who controls the physical substrate. Carnegie has also mapped a labor debate with several competing views on what happens to work. ChinaTalk has argued that AI turns into a political crisis, not just a regulatory one. Spencer Fane, writing from the legal side, frames the domestic picture as a policy crisis driven by exactly the gap between model velocity and rule-making velocity.
These read as separate conversations. They are the same conversation viewed from different layers of the stack. Compute policy is about who can train. Labor policy is about who is displaced by deployment. Domestic patchwork law is about what deployed systems may do. An agent architecture touches all three at once, because it consumes compute, substitutes for labor, and takes consequential action. The reason nobody agrees on how to regulate agents is partly that agents are the point where these three arguments collide.
What builders should do while the argument continues
Waiting for clarity is not a strategy. A few design positions look sound regardless of how the politics resolve.
- Treat jurisdiction as runtime state, not deployment configuration. Pass it explicitly, log it explicitly, let the planner see it.
- Design action boundaries that a non-engineer can name. If you cannot point to the decision, you cannot defend it.
- Make traces reproducible, not just recorded. Pin retrieval snapshots and model versions per action.
- Build for the strictest regime you touch, then relax deliberately rather than accumulating exceptions.
None of this is glamorous. It is plumbing. But the agents now moving into consequential work will be judged by rules written after they shipped, and the systems that survive that judgment will be the ones that recorded enough to answer questions their designers hadn’t heard yet.
The trace log on your screen is a claim about what happened. Make it one you’d be willing to defend.
🕒 Published: