Deterministic Shells Control, Agentic Shells Explore

Every AI agent has a boss. Sometimes the boss is ordinary application code, calling the model for one bounded judgment. Sometimes the boss is the model, deciding what to inspect, what to call, and when to stop. That choice decides the failure mode before the first prompt ever runs.

Name the Boss

A deterministic shell is normal application code with a model call inside it. Your code owns the route. It decides the states, permissions, retries, validation, storage, and UI. The model gets a bounded job: classify this ticket, summarize this transcript, extract these fields, draft this reply, explain this metric.

The model is a component. A powerful component, but still a component.

An agentic shell puts the model in charge of the loop. It reads the task, picks the next move, calls a tool, reads the result, and keeps going. Cursor, Claude Code, OpenClaw, NanoClaw, and similar systems are execution environments for that loop. Files, browsers, terminals, APIs, and code become things the model can reach.

The Agentic Shell matters because the control plane moved.

Deterministic Shells Are for Known Roads

Reach for a deterministic shell when the path is already known.

Support triage. Structured extraction. Onboarding flows. Compliance checks. Customer notifications. Pricing assistants. Weekly reports. The shape of these jobs is not mysterious. The product knows the inputs, the allowed decisions, the outputs, and the places where a human must approve.

Put the model in a box and let code own the rest.

A deterministic shell gives you the boring gifts: tests, schemas, logs, permission checks, retry policy, cost ceilings, latency budgets. You can mock the model. You can replay the state machine. You can tell a customer why the thing did what it did.

It also gives you a product surface. Buttons. Menus. Review screens. Error states. A user should not need to negotiate with a blinking cursor just to get a predictable workflow done.

The price is rigidity. Every new branch becomes code. Every edge case becomes backlog. If the job keeps changing shape while it runs, the deterministic shell starts to feel like a hallway full of locked doors.

The split lines up with the agent taxonomy in Not Every Agent Needs AI. Level 0 and Level 1 systems belong here most of the time. A cron job does not need agency. A sentinel that runs a fixed check and asks the model to explain the result does not need an autonomous runtime. It needs boring code with one intelligent joint.

Deterministic shells are for known work with sharp boundaries.

Agentic Shells Are for Unmapped Work

Use an agentic shell when nobody can write the flowchart honestly.

“Fix this bug” is not a sequence. It is a hunt. The agent may need to read the stack trace, search the repo, run the failing test, inspect a migration, edit one file, break another file, back up, and try again.

Deep research has the same shape. So does incident diagnosis. So does cleaning up a weird data set, comparing vendors, or doing personal assistant work across calendar, email, browser, and files. The valuable step is often the one you could not name before the previous step finished.

That is where an agentic shell earns its keep. It composes tools without a developer wiring every path. It adapts when the next move depends on fresh evidence. It lets a trained human steer through work that used to require handoffs between engineering, ops, research, and support.

The tax is variance.

The same request can take a different path tomorrow. A tool call can wander. Token spend can creep. A broad tool surface can turn one bad instruction into a real incident. If the agent can read files, open browsers, call APIs, and run commands, you have stopped building a chatbot and started operating machinery.

That is where Operators become the missing role. An agentic shell without an Operator is a factory line with no one watching the line. It might produce gold. It might produce scrap. Either way, no one owns the run.

Agentic shells are for unknown work with high context requirements.

The Production Shape Is Hybrid

The production answer is usually a deterministic shell around an agentic core.

The outer shell owns identity, permissions, billing, audit logs, state, retries, approval gates, and the product experience. The inner shell owns the ambiguous run. The app decides what is allowed. The agent decides how to get there.

Picture a production bug assistant.

The deterministic shell receives the incident, checks severity, creates the run record, mounts the permitted repo, injects the dashboards, sets a token budget, and blocks writes until approval.

The agentic shell investigates. It reads logs, searches code, reproduces the failure, drafts a patch, runs tests, and writes the report.

Then the deterministic shell takes back the wheel. It enforces architecture rules with teeth, records the evidence, routes the PR, and waits for signoff.

That is production architecture. Code guards the edges. The agent handles the messy middle.

It also matches the path from Operate Before You Automate. Start by operating the workflow manually inside an agentic shell. Learn the variance. Find the intervention points. Discover what needs to be deterministic. Then move those pieces into code.

Choose by Risk, Not Vibe

Agentic is too coarse a word to design with.

Ask where control belongs.

If failure must be narrow, behavior must repeat, users need a polished surface, costs need a ceiling, or the work is already mapped, keep control in product code.

If the path changes per run, the agent needs rich context, the value comes from composing tools, and an Operator can watch the line, put control in the reasoning loop.

If the work is valuable enough to justify autonomy and risky enough to need rails, split control on purpose.

Context still matters. Your agent’s IQ matches your context, but the shell decides what the agent is allowed to do with that intelligence.

Deterministic shells control. Agentic shells explore. The best systems know which one is driving.