Constrained AI Agents and the Governance Gap

When a regulator asks who authorized an AI agent to take a particular action, "the LLM decided" is not a defensible answer. That's the sentence I kept returning to while watching Mateo Torres, a developer advocate at Arcade, present at Mastra's TypeScript AI Demo Day in San Francisco this April — an event recorded at approximately six minutes and fourteen seconds, though the architecture Torres describes compresses a policy problem that governance frameworks have been wrestling with for considerably longer.

Torres frames his talk as a design pattern question: how do you build an agent that is useful without being dangerous? His answer — "constrained non-determinism," paired with "semi-deterministic orchestration" — is an engineering answer. But the vocabulary maps with uncomfortable precision onto what the EU AI Act's human oversight requirements and the FTC's recent guidance on AI system accountability are trying to compel from the outside. Torres arrived at these constraints from first principles as a builder. Regulators are arriving at the same destination from incident reports, enforcement actions, and political pressure. The gap between those two entry points is where enterprise deployments are currently getting into trouble.

The Architecture as Accountability Framework

Torres opens with a plot of agency against predictability. At one extreme: fully deterministic automation, rigid control flow, no judgment. At the other: what he calls "YOLO mode" — full agency, dangerous permissions, an agent that can do anything. His argument is that neither extreme serves users, and that the productive design space lies between them.

"The sweet spot is something in between where I call semi-deterministic orchestration, which is workflow-looking but it has an LLM component to it," Torres explains. "And then the other thing I call constrained non-determinism, which is more akin to a full agentic workflow, but constrained not to be dangerous — not to exfiltrate data, basically prevent the agent from harming the user."

From a developer's perspective, this is an elegant solution to a hard engineering problem. From a compliance officer's perspective, it's a description of what Article 14 of the EU AI Act requires for high-risk AI systems: human oversight measures that enable operators to "understand the capacities and limitations" of the system and to "intervene on the operation" when necessary. The semi-deterministic layer is, functionally, an audit trail. The constrained non-determinism layer is, functionally, a permissions model. Torres built them because they make better software. Enterprises deploying agents at scale will need them because regulators and insurers are beginning to ask for documentation of exactly these properties.

The OAuth Problem Is Not Just a Dev-World Antipattern

Torres's demo centers on a YouTube admin agent he built to manage Arcade's channel, sponsorships, and competitor research. The system runs on Mastra workflows and Arcade's MCP servers, with the platform described as handling authentication and scoped per-tool tokens — allowing agents to take actions across applications like Slack, GitHub, and Notion without requiring broad OAuth grants. According to Arcade's documentation, this scoping architecture is central to the platform's production-readiness claims, though the specific scope of OAuth coverage varies by integration and is worth verifying against current Arcade documentation before deployment decisions are made.

The problem Torres is solving — agents accumulating broad OAuth permissions that outlive their intended use — is not a niche developer concern. It is precisely the credential mismanagement pattern appearing in enterprise AI audit failures and, increasingly, in cyber insurance underwriting exclusions. An agent granted write access to a GitHub repository, a Slack workspace, and a production database "because it might need them" is an agent that has already failed the principle of least privilege. The IBM principle of least privilege, repackaged for the agent era, is the same constraint Torres is engineering into his architecture.

A guardrail that exists only in a system prompt is not a guardrail in any sense that a breach notification requirement will recognize. When an agent operating under broad OAuth credentials takes a damaging action — deletes records, exfiltrates data, sends unauthorized communications — the question of organizational liability does not hinge on whether the developer intended the agent to behave that way. It hinges on whether the organization took reasonable steps to constrain what the agent could do. Scoped per-tool tokens are reasonable steps. "We told it not to" is not.

Amazon's experience building multi-agent systems at scale reaches a similar conclusion from the operational direction: human oversight isn't a failure mode. It's what makes autonomous systems deployable. Torres's architecture builds that oversight in structurally, not as a patch.

Distillation as Compliance-Readiness

The most practically interesting part of Torres's framework is what he calls the distillation loop. Agents explore; when they find themselves doing the same thing repeatedly, you freeze that repetition into a workflow.

"As I explore and I find myself doing the same thing every time, I freeze that repetition into a workflow, and now I can do that much faster," Torres says.

This is not merely an optimization insight. It is also a description of how regulated industries have always handled the gap between judgment and procedure. A compliance workflow codifies what was once a legal judgment call. A clinical protocol distills what was once a physician's heuristic. The reason regulated enterprises prefer workflows over agent improvisation is that workflows are auditable: you can show exactly what ran, in what order, with what inputs. When the agent side of Torres's architecture reveals a pattern that repeats, distilling it into a Mastra workflow doesn't just make it faster — it makes it provable.

"A workflow is very good at capturing domain knowledge," Torres notes. "You can use the goodness of the agent side to distill that agent into a good workflow that is predictable and optimizable, while still keeping the agent side to reveal patterns that are useful."

The shared memory layer — structured data for workflow optimization, free text for agentic exploration — is the connective tissue. What makes this interesting from a governance standpoint is that structured data is also what makes agent behavior legible to an auditor. The harness engineering approach to making agent behavior deterministic is solving a related problem from a different angle; Torres's contribution is the feedback loop that routes discovery back into auditability.

The Bootstrap Problem and What Enterprises Should Do With It

Torres closes with a recipe for replication: take the architecture diagram, point an agent at the Mastra and Arcade documentation, and tell it what you want. He acknowledges, with some candor, that the repository may not yet be public.

This is the bootstrap problem in plain view. The framework Torres describes is genuinely useful. The evidence — a working YouTube admin agent managing a real channel — is more than most agent architecture talks produce. But the gap between "a developer advocate built this for his own use case" and "an enterprise deploys this against production systems with regulatory exposure" is not closed by an architecture diagram and a reference to documentation.

Enterprises and procurement officers evaluating agentic systems right now should treat Torres's framework as a checklist, not a finished product. Can the vendor document what permissions the agent holds and why? Is there a mechanism for freezing discovered patterns into auditable workflows, or does the system rely on prompt-level constraints that don't survive a clever input? Is the memory architecture structured in a way that produces legible logs — not just for debugging, but for the incident report you will eventually need to write?

Regulators developing AI governance frameworks should also pay attention to what Torres is demonstrating, because the architecture he built voluntarily is closer to what they are trying to mandate than most of the compliance theater currently circulating under the heading of "responsible AI." The EU AI Act's human oversight requirements and the FTC's accountability guidance both gesture at exactly the properties Torres describes: constrained permissions, auditable decision paths, human intervention points. The question is whether those frameworks will create incentives for this kind of architectural rigor — or whether they will be satisfied by documentation that describes the intent without requiring the structure.

The answer to that question will determine whether "constrained non-determinism" remains a developer pattern or becomes a term of art in the next generation of AI liability litigation.

---

Samira Barnes covers technology policy and regulation for Buzzrag.