So Daniel sent us this one — he wants to dig into the mechanics of how AI agents actually select and invoke tools. Specifically, the spectrum between fully autonomous tool selection, where the model just picks whatever it wants, and deterministic approaches where the architecture prescribes exactly which tools are available at each step. He's asking about Claude's native tool use, OpenAI function calling, AutoGPT-style loops on the autonomous end, versus LangGraph state graphs, CrewAI's role-based assignment, Bedrock and Azure's structured orchestration on the other. And the middle ground — LangChain's AgentExecutor, Semantic Kernel, Claude Code's permission gates. The security angle, the token economics, the observability question. And the core question: is production experience pushing the industry toward more constrained orchestration, or will better models eventually make fully autonomous tool use the default?
Herman Poppleberry here, and I have been thinking about this exact question for weeks. Because there's a framing problem in how most people approach this debate — they treat it as a capability question, like autonomous is more powerful and deterministic is just a safety blanket for teams that don't trust their models yet. But the production data is telling a completely different story.
By the way, today's script is being generated by Claude Sonnet four point six, which I find darkly amusing given we're about to spend twenty-five minutes talking about how to constrain what Claude is allowed to do.
The irony is not lost on me. Okay, so let's start with the token economics, because I think this is the thing most people genuinely haven't internalized. When you give an agent access to forty tools via MCP, you're not just giving it options — you're loading roughly eight thousand tokens of schema into its context window before it has done a single thing. That's the baseline tax for autonomy.
Eight thousand tokens just for tool descriptions.
For forty tools, yeah. A single tool schema — something like a create pull request endpoint with seven parameters — runs about two hundred tokens. Forty tools times two hundred tokens, you're at eight thousand before the system prompt, before the user message, before any history. Now connect two or three MCP servers, which is completely normal for a real workflow, and you're burning twenty to thirty thousand tokens on descriptions alone. Anthropic's own measurements found standard MCP workflows consuming around a hundred and fifty thousand tokens for multi-tool operations that could execute in roughly two thousand tokens with proper architecture. That's a ninety-eight percent reduction.
Okay, I want to sit with that number for a second, because that seems insane. Ninety-eight percent of the token budget going to telling the model what tools exist, rather than actually doing the work.
And here's the framing that makes it click — Praetorian, the security firm, ran empirical analysis and found that token usage alone explains eighty percent of performance variance in agent tasks. They called it the Context-Capability Paradox: to handle complex tasks, agents need comprehensive instructions and tool access. Comprehensive tool access consumes the context window. Consumed context reduces the model's ability to reason about the actual task. So the thing you're loading to make the agent capable is actively degrading its capability.
So the autonomous approach is essentially eating itself.
In large-scale deployments, yes. And this is what drove the industry toward what Praetorian calls Just-In-Time loading, or the Librarian Pattern. Their platform has two tiers — forty-nine high-frequency skills that are always registered as tools, and three hundred and four specialized skills that are completely invisible to the model until it explicitly requests them via a read call. Their comparison is stark: five MCP servers in the legacy model consumed seventy-one thousand eight hundred tokens at startup — thirty-six percent of a two-hundred-thousand token context window — before the agent had processed a single user request. The wrapper model: zero tokens at startup.
That's a genuinely different architecture. You're not constraining what the agent can do, you're constraining what it can see.
Which is the more principled version of the argument. And it maps onto how the deterministic frameworks approach this from a different direction. LangGraph's core insight isn't just about safety — it's that if you model your workflow as an explicit state graph, tools are only presented at the nodes where they're relevant. A data retrieval node doesn't load the email-sending tools. A summarization node doesn't load the database write tools. The context at each step is exactly what that step needs.
And you get that for free as a side effect of the architecture, not as an explicit security decision.
Right, it's structural rather than policy-based. Compare that to CrewAI's approach, which I think is underrated in this conversation. CrewAI has a two-level tool assignment system — agent level, where a tool is part of the agent's general toolkit across all tasks, and task level, where a tool is available only for a specific task and actually overrides the agent-level assignment. The community framing on this is blunt: if you really don't want the model to push a certain button, it's probably best not to let it see that button at all. Their point is that LLMs are fundamentally stochastic — randomness is part of their DNA — so the question isn't whether the model will misuse a tool, it's whether you can guarantee it won't. And with probabilistic systems, you can't.
That's the philosophical crux, isn't it. Is this a current-generation limitation that better models will eventually overcome, or is stochasticity a permanent property of these systems that no capability improvement resolves?
I lean toward the latter, honestly. The argument that sufficiently capable models won't need tool constraints assumes that capability and reliability are the same thing. But a more capable model that's still fundamentally probabilistic is just a more capable source of unpredictability. The jackhammer problem doesn't go away because the model gets smarter — it gets more consequential, because now the model can do more damage with the wrong tool.
The jackhammer problem being: you gave a plumber a jackhammer to change a faucet.
CrewAI's exact framing, and it's a good one. Now let's talk about the middle of the spectrum, because I think this is where the most interesting design thinking is happening. Amazon Bedrock's comparison between ReAct and ReWoo is a concrete illustration of the autonomy-efficiency trade-off made quantitative. ReAct — Reasoning and Action — is the default, iterative approach: model analyzes a step, decides next action, executes, observes result, repeats. For N steps, you need at least N plus one model calls. ReWoo — Reasoning Without Observation — generates a complete task plan upfront and executes without checking intermediate outputs. Maximum two model calls regardless of complexity.
So for a six-step task, ReAct is seven model calls, ReWoo is two.
And in production testing with Claude Sonnet three point five v two, Bedrock measured fifty to seventy percent latency reduction with ReWoo on complex queries. A task taking eighteen seconds with six model invocations under ReAct took nine seconds with two under ReWoo. The trade-off is real though — ReWoo can't adapt if intermediate results change the plan. If step three returns something unexpected that should change step four, ReWoo doesn't notice. ReAct would catch that. So you're trading adaptability for efficiency, and the right choice depends entirely on how predictable your task domain is.
Which suggests the answer to autonomous versus deterministic isn't a single answer — it's a function of the task.
That's Microsoft's explicit guidance from their Azure Architecture Center, updated February of this year. They define five orchestration patterns: Sequential, which is linear and deterministic; Concurrent, where parallel agents handle the same input; Handoff, where dynamic delegation passes control with one active agent at a time; Group Chat, where a chat manager controls conversational turns; and Magentic, which is the most open-ended, dynamic task ledger approach for genuinely novel problems. And their top-line recommendation is: start with a direct model call. Escalate to a single agent with tools only when that demonstrably fails. Escalate to multi-agent only when single-agent demonstrably fails. The complexity spectrum is a last resort progression, not a default.
Ninety percent of successful production AI systems are workflows with strategic LLM calls, not fully autonomous agents. That stat keeps coming up.
It's from the Agentic AI Trends data and it aligns with everything practitioners are reporting. The AWS re:Invent framework from December was similar — low complexity plus low autonomy means function calling, single shot, deterministic. Moderate complexity with adaptive reasoning means single agent with ReAct. High complexity with multiple domain collaboration means multi-agent. And the key principle they kept repeating: always start simple. Don't overcomplicate the problem.
Okay, but let's steelman the autonomous side for a minute, because there is a genuine argument here. The thing deterministic pipelines can't do is discover tool combinations the architect didn't anticipate. If you've hardcoded a state graph, the agent can only execute paths you've imagined. Autonomous selection can find paths you haven't.
This is the Novel Combination Argument, and I think it's real but narrower than its proponents claim. In research and exploration tasks — Anthropic's multi-agent research systems are the clearest example — autonomous combination probably does generate value. A model combining a web search tool with a code execution tool with a file write tool in a sequence a human wouldn't have prescribed, and solving the problem more elegantly. That's genuinely happening.
But in production software development, the Praetorian data suggests the value comes from reliable execution of known patterns, not novel discovery.
Their conclusion is stark: the primary bottleneck in autonomous software development is not model intelligence, it's context management and architectural determinism. Current agentic approaches fail at scale because they rely on probabilistic guidance — prompts — for deterministic engineering tasks like builds, security, and state management. Their solution is what they call the Thin Agent, Fat Platform inversion. Agents are stateless workers under a hundred and fifty lines. The platform has three hundred and fifty plus prompts and thirty-nine plus specialized agents managed like software artifacts with CI/CD. They're treating LLMs as unreliable microservices that need to be wrapped in reliable infrastructure.
That framing is interesting because it's not anti-AI — it's the same pattern that made cloud computing work. You don't trust any individual node. You build the reliability into the infrastructure around the nodes.
And the tool restriction boundaries they've implemented make this concrete. The orchestrator agent has access to Task, TodoWrite, and Read. It physically cannot access Edit or Write — it cannot write code. It must delegate to a worker. The worker has Edit, Write, and Bash. It physically cannot access Task — it cannot delegate. It must work. The architectural constraint enforces the separation. It's not a prompt that says "don't write code yourself" — it's a permission boundary that makes writing code yourself structurally impossible.
Which brings us to the security angle, because this is where the autonomous versus deterministic debate stops being an engineering preference and starts having real consequences.
The numbers here are alarming. OWASP's LLM Top Ten for 2025 put Prompt Injection at number one. HackerOne's Hacker-Powered Security Report documented a five hundred and forty percent surge in valid prompt injection reports — fastest-growing AI attack vector. And MCP specifically has had a rough run. In March 2025, security firm Equixly found command injection vulnerabilities in forty-three percent of tested MCP implementations. Thirty percent vulnerable to server-side request forgery. Twenty-two percent allowing arbitrary file access.
Forty-three percent is not a rounding error. That's nearly half of tested implementations.
And it gets more specific. May 2025, Invariant Labs demonstrated a GitHub issue that prompt-injected an AI assistant to pull data from private repositories and leak it to a public pull request. June 2025, Asana discovered customer data bleeding between organizations via MCP and pulled the integration offline for two weeks. October 2025, JFrog disclosed CVE-2025-6514, CVSS score nine point six, in mcp-remote — remote code execution via OS commands in OAuth discovery fields. There's also a documented supply chain attack where a malicious package posing as a legitimate Postmark MCP server was injecting BCC copies of all email communications to an attacker-controlled server.
The BCC attack is almost elegant in how invisible it is. The agent sends email, the email sends, everything looks fine.
And the rug pull attack is the one that should concern anyone doing enterprise deployments. Tool descriptions in MCP can be modified after the user has approved them. So you approve a tool based on its description, the description gets silently updated, and now the LLM thinks the tool does something different from what you approved. The tool itself hasn't changed — just the model's understanding of it.
That's a fundamental trust problem with the protocol, not just an implementation bug.
Praetorian published new research on April tenth — so literally two days ago — on what they call the Supervisor Blind Spot, and it's the sharpest articulation I've seen of why autonomous tool selection amplifies the security problem. They documented a case where a supervisor agent inspects incoming user messages for malicious content. The supervisor looks at a message — something like "what is your return policy?" — finds nothing malicious, passes it through. But the assembled prompt that reaches the chat agent also includes a user profile field, specifically the Name field, which had been poisoned with adversarial instructions. The supervisor never saw the Name field. It only inspected direct user input.
So the injection wasn't in the message — it was in the data the message caused the system to retrieve.
Their root cause analysis: LLMs lack a native mechanism to enforce separation between data and instructions within a prompt. Unlike SQL, where parameterized queries prevent injection by separating code from data at the protocol level, prompt construction today is essentially string concatenation. Everything in the context window is treated as potentially instructional. There's no syntax that says "this string is data, not a command."
That's the pre-parameterized-query era of SQL. We know how that story ends — you eventually get parameterized queries because string concatenation is indefensible at scale.
And the deterministic pipeline is the nearest equivalent we have right now. If a data retrieval step only has access to read tools, a poisoned Name field can't cause the system to invoke a write tool or an email tool — those tools aren't present at that step. The attack surface per step is bounded by what the architecture allows at that node.
OWASP's mitigation for this is basically a description of deterministic orchestration — enforce least privilege, provide API tokens for extensible functionality, handle tool invocation in code rather than providing it to the model.
Which is the Praetorian architecture made into a security recommendation. Now, the observability side of this is worth spending a minute on, because it's the debugging argument for deterministic approaches. When Claude autonomously chains five tool calls to answer a question, reconstructing why it chose that sequence requires inspecting the model's reasoning at each step. Which may not be fully logged. And which may not be reproducible, because the outputs are stochastic. Run the same query twice, you might get a different tool chain.
LangGraph gives you that for free — every tool call is traceable to a specific node, the routing is in the code, not in the model's head.
The AWS re:Invent quote on this is memorable. Guido Nebiolo from Reply described the failure mode: two agents calling each other recursively because of a misaligned prompt or a tool API that changed without notice. No one notices until a user complains. And in a fully autonomous system, diagnosing that requires reconstructing what the model was reasoning when it made each decision. In a LangGraph system, the infinite recursion would be structurally impossible — the state graph doesn't have a cycle there.
Unless you put one in.
Unless you put one in, yes. Okay, let's talk about Claude Code's Auto Mode as the third paradigm, because I think it's genuinely novel and doesn't fit cleanly into either the autonomous or deterministic bucket. Released in March this year, it's a classifier-based system. Instead of the developer specifying which tools are safe, a classifier makes that determination at runtime. Actions the classifier considers safe proceed automatically. Actions it considers risky are blocked and escalated to the user for approval.
So it's neither the architect deciding upfront which tools are available, nor the model freely choosing among all tools. It's a runtime probabilistic constraint on the model's tool choices.
And the trust model is specific — the classifier trusts the local working directory and configured git remotes, treats everything external as untrusted until explicitly configured otherwise. Anthropic's framing is "a middle path that lets you run longer tasks with fewer interruptions while introducing less risk than skipping all permissions entirely." It requires administrator approval to enable, runs only on Sonnet four point six and Opus four point six, and has a small impact on token consumption and latency per tool call. The open question is whether this just pushes the trust problem one level up — now you're trusting the classifier, and the classifier is itself probabilistic.
You've replaced "trust the model to pick the right tool" with "trust the classifier to assess whether the model picked a safe tool." That's a regression in one sense — you've added a layer — but it might be a better-calibrated layer.
The security argument for it is that the classifier is a much narrower task than the full agent task. Assessing "is this file write operation safe given this context" is easier to get right than "plan and execute a complete software development workflow." Narrow probabilistic systems are more reliable than broad ones.
Which is the same argument for microservices over monoliths. Decompose the problem into smaller, better-bounded components.
And that brings us to UTCP — Universal Tool Calling Protocol — which appeared in July 2025 as a more radical alternative to MCP entirely. The idea is that instead of a live MCP server that the agent queries, you give the agent a JSON manual describing how to call tools directly via native endpoints — HTTP, gRPC, WebSocket, CLI. No wrapper layer. Independent benchmarks showed sixty percent faster execution, sixty-eight percent fewer tokens, and eighty-eight percent fewer round trips for complex multi-step workflows compared to MCP. It's more deterministic in character — the agent gets a manual and calls endpoints directly, rather than discovering capabilities from a live server.
The MCP roadmap for 2026 is also moving in this direction — scalable stateless session handling, better enterprise authentication, audit trails, a Server Card format for capability discovery without a live connection. The protocol itself is evolving toward more structure.
Which is the meta-signal here. Every layer of the stack is trending toward more constraints, not fewer. The protocol is adding structure. The frameworks are adding determinism. The orchestration architectures are adding enforcement hooks. Praetorian's eight-layer enforcement system wraps deterministic constraints around the LLM at every level — session start rules, per-prompt reminders, pre-tool-use blocks, post-tool-use validation, quality gates on exit. They parse Claude Code's session transcripts, the JSONL files under the dot-claude directory, to programmatically track token usage. Context above eighty-five percent of the two-hundred-thousand token window triggers a hard block on spawning new agents.
That's the compaction gate. And the self-annealing roadmap is the part that I find genuinely interesting — when an agent fails a quality gate more than three times, a Meta-Agent spawns with permission to modify the configuration directory, diagnoses what they call the Rationalization Path the agent used to bypass instructions, patches the skill or hook, and creates a pull request labeled self-annealing. The system gets stronger with each failure.
It's treating the agent architecture as a software artifact that evolves under CI/CD rather than a static configuration. Which is the correct mental model — if you're running three hundred and fifty prompts as part of your production system, those prompts are code. They should be versioned, tested, reviewed, and improved continuously.
So where does this land on the core question? Is the industry trending toward constraints, or is this a temporary phase?
I think the evidence is unambiguous that production is forcing constraints. Ninety percent of successful production systems are workflows with strategic LLM calls. The token economics make fully autonomous multi-server deployments expensive and context-degrading. The security breach timeline makes unconstrained tool access a liability. The observability requirements make autonomous chains hard to debug and audit. All of those pressures point the same direction.
But the counter-argument isn't just theoretical. Anthropic's multi-agent research systems are genuinely doing novel combination work. The question is whether that use case — open-ended research and exploration — is the dominant use case, or whether it's the exception.
My read is that it's the exception by volume, but it's the use case that captures the imagination. Most production agent work is structured tasks — code generation, data processing, customer service workflows, document analysis. Those tasks benefit from deterministic orchestration. The open-ended research use case is real, but it's a minority of deployments, and even there you'd want bounded autonomy rather than unconstrained access to all tools.
The Thin Agent, Fat Platform framing is probably the right synthesis. You don't eliminate autonomy — you scope it. The agent has genuine autonomy within a well-defined execution context, but the platform controls what that context contains, what tools are visible, what actions are permitted. The intelligence is in the platform design, not in the agent's freedom.
And that's actually how reliable software systems have always been built. You don't build reliability by trusting every component to behave correctly. You build it by designing systems where misbehaving components have bounded impact. The LLM is a powerful component that is fundamentally non-deterministic. The right response isn't to wish it were deterministic — it's to wrap it in infrastructure that makes its non-determinism manageable.
Which is a more sophisticated relationship with the technology than either "trust it completely" or "constrain it to uselessness."
The teams getting the most out of these systems right now are the ones who've internalized that distinction. Praetorian's sixteen-phase orchestration template, Microsoft's five-pattern framework, Bedrock's ReAct versus ReWoo decision tree — these aren't limitations on what agents can do. They're the scaffolding that makes agents reliable enough to actually deploy.
There's a practical takeaway buried in the token economics that I don't think enough teams have acted on yet. If you're running MCP servers and haven't audited your context footprint, you might be burning thirty thousand tokens per request on tool descriptions for tools that are almost never called. That's not an abstract concern — that's a direct cost and a direct performance hit.
The JIT loading pattern is not hard to implement. You have a core set of tools that are always available, and a discovery mechanism that loads additional tools on demand. The model asks for a tool by category or name, the platform loads the schema, the model uses it. The context window stays clean for actual reasoning. It's worth measuring before assuming your architecture is fine.
On the security side — the supervisor blind spot research is fresh enough that most teams haven't incorporated it. If you have a supervisor agent doing content inspection, it needs to inspect the full assembled prompt, not just the direct user input. Profile fields, retrieved documents, tool outputs — all of those are injection surfaces.
The parameterized query analogy is the right mental model for where this needs to go eventually. You need a protocol-level distinction between data and instructions, not just a policy that says "treat retrieved content carefully." Until that exists, the architectural mitigation is deterministic pipelines with least-privilege tool assignment at each step.
Alright. This is one of those topics where the more you dig, the more the complexity reveals itself. The autonomous versus deterministic framing is almost too simple — the real question is where on the spectrum a given task warrants, and whether your platform is designed to enforce that position reliably.
And the industry's answer, coming from Microsoft, AWS, Anthropic, and the practitioners doing this at scale, is remarkably consistent: start simple, add complexity only when you can demonstrate it's necessary, and build your reliability into the infrastructure rather than hoping the model provides it.
Thanks as always to our producer Hilbert Flumingtop for keeping this show running. Big thanks to Modal for providing the GPU credits that power the generation pipeline behind every episode. This has been My Weird Prompts. If you haven't followed us on Spotify yet, that's probably the easiest way to get new episodes as they drop. Until next time.
See you then.
