Agentic AI isn't a model, it's a permission. Six steps before an agent touches anything

Agentic AI isn’t a model, and it isn’t a product. It’s a permission. The moment you let an LLM pick the next call and run it without a human approving, you’re agentic. Until then you have a chatbot with a lot of tabs.

I know that sounds petty next to March 16, 2026, the day Nvidia launched Vera, a CPU “purpose-built for agentic AI.” Or next to the MIT Sloan and BCG survey from spring 2025, where 35% said they had already adopted agents and another 44% planned to. But ask anyone who has run an agent against a real system what changed for them. They won’t say “the model.” They’ll say that whatever calls the API, the database and the repo is no longer code a developer wrote and reviewed.

The word stuck in spring 2024, when Andrew Ng started pushing “agentic workflows” in his talks. By January 2025 Jensen Huang was calling it a “multi-trillion-dollar opportunity” at CES. Fine. A name isn’t a method. The question is what you do Monday morning when someone on the team says “let’s make this agentic.” Here are the steps, in the order I’d do them.

01 · Write down who decides each step

First, take the workflow and break it into steps. Next to each step, write two things: who decides, code or model, and what it touches, read or write. That’s the whole exercise.

What you’ll see: most steps don’t need a model at all. Parsing, routing by type, retries, output formatting. Those are all rules. In our daily pipeline, every place we swapped an LLM call for a rule got cheaper and more stable. You’ll also find one or two steps where the model both chooses and writes. That’s your real agentic part, and that’s where all the work in the next steps goes.

The artifact: a three-column table in the project README. Step, decider, touches. If no row has the model writing, you don’t have an agentic problem. You have RAG, and that’s perfectly fine.

02 · Give the agent its own identity

In October 2025 the OpenID Foundation published a 33-page white paper on identity for agents. The bottom line: OAuth 2.1 works well inside a single trust domain, when the agent runs synchronously against internal tools. It starts to creak when the agent crosses domains, runs asynchronously, or acts on behalf of several users at once.

In practice: don’t run an agent on your personal token or on a shared service account. Give it a separate identity, with a scope per tool, a short-lived token (15 minutes, not a year) and a log that records what it did and on whose behalf. If the agent works through MCP, check that the server authorizes every tool call, not just the initial connection.

What you’ll see: the audit log can suddenly tell “Danny deleted it” apart from “Danny’s agent deleted it.” Without that, after an incident you don’t even have a starting point for the conversation.

03 · Harden the database against its caller

In March 2026 Arpit Bhayani published a post every DBA should read. His claim: all our databases rest on a contract nobody wrote down. The caller is deterministic code, the queries are predictable, and a developer reviewed them. An agent doesn’t work that way. It reaches a query through reasoning, can run a five-table join nobody has ever run, and can hold the connection open while it thinks. A 30-second query from a human is a bug someone will notice. From an agent, it may be a loop nobody is watching.

So the protection goes on the role, not in the app:

CREATE ROLE agent_worker LOGIN CONNECTION LIMIT 5;
ALTER ROLE agent_worker SET statement_timeout = '5s';
ALTER ROLE agent_worker SET idle_in_transaction_session_timeout = '10s';
ALTER ROLE agent_worker SET default_transaction_read_only = on;
GRANT USAGE ON SCHEMA analytics TO agent_worker;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics TO agent_worker;

One caveat: the session can override default_transaction_read_only. It’s a belt, not a safe. The real protection is the GRANT: if the role has no write privilege, it can’t write.

What you’ll see after you run it: the agent starts hitting timeouts you never saw before. Good. Each one is a loop that would have run forever. Return the error to the agent as text so it tries a narrower query, and count how many you get per day.

04 · Put a checker inside the loop

In June 2026 Bayer published the story of PRINCE on Martin Fowler’s site. It’s an agentic RAG system for preclinical data. They split the work into separate stages: research, reflection, writing. Around the model they built everything people now call a harness: retries, fallbacks, validation, reflection loops, observability and human review. When they started, they didn’t even use those words.

OpenAI reached the same conclusion from another direction. On July 28, 2026 they published a field report on 8 scientific computing projects, five using Codex alone and three using Codex plus Claude Code:

Now, the bottleneck is validating an AI agent’s output, which still depends on human judgement. — OpenAI, Scientific computing in the age of agentic AI

In short: every step where the model writes needs a checker that runs before the result moves on. A schema for JSON, tests for code, a second model for text, and for the heavy cases, a human. The agent isn’t done when it says it’s done. It’s done when the checker passes.

The artifact: written stop conditions, with numbers. At most 20 steps per task, at most two attempts at the same tool with the same parameters, and a token cap. Cross any of them and the task stops with a clear error instead of quietly carrying on.

05 · Human gates only where there’s no undo

In July 2025 Replit’s agent deleted a production database belonging to Jason Lemkin of SaaStr, in the middle of a code freeze it had been explicitly told about. Amjad Masad, the CEO, apologized publicly and promised automatic separation between dev and production databases. In other words, the fix wasn’t a better prompt. The fix was a permission.

So do you put human approval on every step? No. After two days everyone clicks “approve” without reading. Put it only on actions you can’t undo: DROP and deletes, production deploys, emails to customers, payments. The Ship-Code template in AgentSwarms does exactly that: agents plan, write and review the diff, and the deploy stops at a human-approval node.

My take: I don’t buy “full autonomy” as a goal. In a good agent setup, a human approves twice a day, not zero times. The metric is how many approvals are left after you’ve built all the guardrails, and whether every one of them actually gets read.

06 · Practice on someone else’s agent

On July 16, 2026 Capital One open-sourced VulnHunter. It isn’t a passive scanner. It’s an agent that hunts for exploitable flaws, maps attack paths and proposes a targeted fix in the code. For you, it’s a ready-made practice ground.

Before you build an agent that touches your code, clone github.com/capitalone/vulnhunter, run it against one internal service inside a sandbox, and write down three numbers: which tools and permissions it asks for, how many steps a task takes it, and how many of its fixes pass your tests untouched. That’s a free internal benchmark, and it gives you a baseline for the stop conditions from step 04.

And if you already run several agents in parallel, say Claude Code, Codex and Cursor, tools like AgentsDock put them all on one screen, phone included. Handy. Just remember that every screen like that is one more place where someone can approve an action on the train without reading what they’re approving.

What to take away

• A “who decides, what it touches” table before the first line of code. Most rows will turn out to be rules.
• A separate identity and a separate DB role per agent, with timeouts set on the role.
• A checker inside the loop and stop conditions with numbers. The model saying “done” doesn’t mean done.
• A human gate only on what you can’t undo. Approval on every step is theater, and after a week nobody reads it.