Are You Ready for Agentic AI? The Readiness Check That Comes After the First One

A few weeks ago we wrote about the AI readiness check every small business should do before spending a dollar. That piece was about whether you should start with AI at all. Most businesses needed to fix a process or start logging data before AI was even a fair conversation.

The conversations we've had since that piece went out keep landing on the same next question. Companies that already shipped something simple, a scheduling assistant, a document summarizer, a chatbot that handles the same twenty customer questions all night, are now being pitched the next thing: agents.

The pitches sound like the chatbot pitches from a year ago, only louder. And every vendor has a slightly different definition of what "agentic" even means.

Here is the part that matters. Whatever the vendor calls it, the difference between an AI tool and an AI agent is the same single thing: an agent takes action. A chatbot tells your customer their order shipped. An agent ships it. A copilot drafts an email. An agent sends it. A reporting tool flags a duplicate vendor invoice. An agent puts it on hold.

That difference is not a feature upgrade. It is a different kind of trust. And it needs a different kind of readiness check.

Why the old readiness check doesn't cover this

The old check asked three things. Do you have a real process? Do you have data? Do you know what win you're chasing? Those still apply. But they were enough when AI was answering questions and you were the one acting on the answers.

The moment AI is doing the acting, five new questions appear. None of them are about the AI. All of them are about your business.

1. What happens if it does the wrong thing?
2. Who is it acting as?
3. Can you tell what it did, and undo it?
4. What stops the cost from running away?
5. Where does a human still have to nod?

That set is what we'll walk through. We've worked with companies through both checks, and the second one trips up businesses that thought they were AI-mature. Being ready to use AI and being ready to delegate to AI are not the same readiness.

1. Blast radius

Before you grant an agent the ability to do anything, write down the worst thing it can do.

Not the worst thing you imagine it will do. The worst thing it can do given the permissions and tools you're about to grant it. Read the API scope. Look at the database access. Be honest.

If the answer is "send a misformatted email," the blast radius is small. Ship it.

If the answer is "refund a customer who shouldn't be refunded," the blast radius is medium. You need approval thresholds.

If the answer is "publish a public statement on our behalf," "wire money," "change a customer's policy coverage," or "modify a production database," the blast radius is large. Those agents need hard constraints. Per-action limits. Approval gates. A human signoff for anything above a threshold you can defend in writing.

The reason this matters: agents don't know they're doing the wrong thing. They follow instructions, the instructions are sometimes ambiguous, and the model occasionally makes a leap of logic that nobody asked it to make. Limit the damage before you discover which leap it's going to make first.

2. Identity and permissions

Agents need to log in to do anything useful. That means agents need accounts.

Most companies stumble on this in the same way. They give the agent a senior employee's credentials. Or they create a generic "service account" with admin rights because it was easier than figuring out the right scopes. Or they hand it an API key with no expiration, no scope limit, and no audit trail tying actions back to a specific run.

If you wouldn't give a new hire admin access on day one, don't give it to your agent.

Three rules we use on every engagement:

• Every agent has its own identity. Not a shared service account, not a human's credentials. An identity you can revoke without breaking three other systems.
• Scope to the smallest thing it needs. If it only needs to read invoices, it only gets read on invoices. If it needs to write to one table, that's all it touches.
• Every action is logged with the agent's identity attached. When something goes wrong, "the agent did it" is not an answer. "Run ID 8472, acting as agent-invoice-reconciler, called update_invoice_status at 14:32" is.

This sounds like an IAM nerd's hobby until the first time an agent does something a regulator asks you to explain.

3. Auditability and reversibility

When an agent makes a mistake, you need two things fast. A clear record of what it did, and a path to undo the parts that matter.

Auditability is the boring half. Log every action the agent took, the inputs it received, the prompt or instruction that drove it, the tools it called, and the result of each call. If your platform doesn't make this trivial, you're going to regret it the first time something goes sideways. Treat agent logs the way you'd treat security logs. Append-only, queryable, retained.

Reversibility is the half nobody plans for. If an agent sent 400 emails, can you tell which ones, to whom, and unsend the ones that shouldn't have gone out? If an agent updated 60 customer records, can you roll them back? If it placed an order, can you cancel it?

Not every action is reversible. Some money you can't get back. Some emails you can't unsend. The way through this is not to refuse irreversible actions. It is to design where they live. Reversible actions can be automated freely. Irreversible actions need a human checkpoint or a tight constraint, ideally both.

The question to ask before launch: if this agent does the wrong thing 100 times in an hour before anyone notices, how bad is the cleanup?

4. Cost containment

This is the one that catches finance teams off guard.

An agent doesn't run a fixed amount. It decides how much work to do based on what it sees. It loops. It retries. It calls models recursively when it gets stuck. It calls tools that call other tools. A single user request can fan out into 30, 50, 200 model calls.

In practice this means a few things you have to plan for from day one:

• Hard ceilings per run. Maximum model calls, maximum tool calls, maximum tokens, maximum runtime. Pick numbers that are generous for the happy path and intolerable for runaway behavior.
• Hard ceilings per day. Same idea, one layer up. If the agent burns its daily budget by noon, something is wrong and you'd rather know about it than discover it on the bill.
• Alerts before ceilings hit. "We crossed 60% of the daily budget" is a better email than "we crossed 100% three hours ago."

Use these limits even when you're confident in the design. We've watched well-tested agents loop on an edge case for hours after an upstream API started returning malformed data. The agent kept retrying, kept calling the model, kept paying for the calls. The ceiling caught it.

5. Human-in-the-loop, designed not retrofitted

The temptation is to put humans either everywhere or nowhere. Both are wrong.

Everywhere means a person has to approve each action. The agent stops being useful. You may as well not have built it.

Nowhere means the agent does everything autonomously. That works until it doesn't, and the day it doesn't is usually the day a regulator or a customer or a CEO calls.

The right answer is selective. Pick the actions where the cost of being wrong is high enough that human review is worth the latency. Examples that almost always need a human:

• Anything involving money above a threshold
• Anything sent to a customer that can't be unsent (legal commitments, policy changes, public communication)
• Anything affecting more than N records in a single run
• Anything outside the agent's normal scope of work

Build approval queues for those. For everything below the threshold, let the agent run.

This isn't a one-time decision. Thresholds creep up as confidence grows, and they should creep up. The wrong move is to set them once and forget. The right move is to revisit them after every quarter of running data.

The agent-readiness checklist

Before you let an agent take its first action, be able to answer yes to these.

1. I can describe the worst thing this agent can do given its permissions and tools
2. The agent has its own identity, with the smallest scope it needs to function
3. Every action it takes is logged with its identity and a run ID
4. I have a plan for undoing the actions that matter most if it does the wrong thing
5. I have hard ceilings on cost and runtime per run and per day
6. I know which actions require a human approval and which ones don't
7. I have a way to find out when something went wrong, fast, without depending on the agent to tell me

Seven questions. None of them are about the model. All of them are about your operational discipline.

If you can answer yes to all seven, ship the agent. If you can't, the gaps tell you what to build before the agent starts working.

The biggest mistake we see

Treating an agent like a chatbot.

The pitches sound the same. The demos look the same. The vendor probably uses the same slides. So companies plug agents into their systems the same way they plugged chatbots in, with the same level of access, the same monitoring, the same expectations.

Chatbots answer. If the answer is wrong, a customer is annoyed and your support team handles it. Agents act. If the action is wrong, your support team is the least of your problems.

The companies that get agentic AI right treat the agent like a new employee with a credit card, a calendar, and write access to systems. They scope its responsibilities, define its limits, audit its work, and grow its authority as trust builds.

The companies that get it wrong skip those steps because the chatbot didn't need them. They find out the difference the hard way.

Where to start

If you're earlier in the journey: build one. Pick a low-blast-radius workflow. Internal use only. A finance reconciliation step, a procurement triage queue, a meeting summarizer that posts to a private channel. Give it the smallest scope it needs. Watch what it does. Adjust. Don't put it in front of customers until it's been running quietly on internal work for a month.

If you're further along and considering customer-facing agents: scale the readiness check up. Bigger blast radius needs harder constraints. The five categories above don't change. The thresholds do.

The technology is ready. Bedrock, the major frontier models, and the open-source frameworks all support real agentic patterns now. What's not ready, in most businesses, is the surrounding apparatus. Identity. Auditing. Cost controls. Approval flow. Reversibility planning.

The good news is that none of that is exotic. It's what your security and operations teams already know how to do. It just needs to be done before the agent ships, not after.

---

Written by Ramesh Nori. If this was useful or you have feedback, reach me at cloudbuckle@gmail.com.