The word “agentic” gets cheaper every quarter. It started as a genuinely useful technical distinction, and it has drifted into a label that gets attached to more or less anything with a language model somewhere inside it. We care about that for a practical reason rather than a semantic one: when a term stops discriminating between things, the buyer loses the ability to tell what they are paying for. “Agentic AI” has largely become consulting-speak for expensive, over-engineered systems, and the operators we work with — healthcare practices, owner-run SMEs, businesses where the founder still knows every line item — are precisely the people who can least afford to discover that a year in.
So we hold ourselves to a stricter definition. We would encourage you to hold us, and everyone else bidding for the work, to the same one.
The definition we hold ourselves to
A true agentic system means autonomous software agents that perceive their environment, make decisions, and take actions to achieve specific goals — without constant human supervision.
That last clause is the test. Everything before it describes almost any piece of software written in the last forty years, if you squint. The independence is what makes the category distinct, and it is the part that quietly disappears from most proposals. If a person has to sit in the loop on every step — approving each read, confirming each write, clicking through each decision — it isn’t an agent. It’s a workflow with a chatbot attached.
We want to be fair here, because there is nothing wrong with a workflow with a chatbot attached. We build them. For plenty of processes it is the correct answer, and it is cheaper, faster and safer than autonomy. The problem is only ever the mismatch: paying agentic prices, absorbing agentic risk, and running an agentic-sounding change-management programme in order to end up with something a well-designed form and a good draft-generation tool would have delivered in a fortnight.
Three questions worth asking before you sign anything
Here is the shortest diagnostic we know. Ask any vendor — including us — to name the goal the agent is pursuing, the actions it is permitted to take on its own, and what it perceives in order to make those decisions.
That is it. Three answers, and they should be specific enough to write on a single page without hedging. Not “improve patient communication” but the actual objective the system is optimising toward. Not “integrates with your systems” but the enumerated list of things it may do without asking anyone first. Not “leverages your data” but the specific records, fields and signals it reads at the moment of deciding.
If those three answers aren’t concrete, the budget is buying architecture diagrams rather than autonomy. We have never once seen a team that had genuinely built the thing struggle to answer them, and we have rarely seen a team that hadn’t manage it at all.
The three layers, and why we think about it that way
Our stack is three layers, and the honest reason it is three is that the definition above already contains them. Perceive, decide, act. That is not a framework we invented to sound rigorous; it is what an agent structurally has to do, so it is where the seams naturally fall. The value of naming the layers is that each one can then be argued about, priced and replaced on its own.
The context layer
An agent can only make good decisions about what it can actually see. In most small and mid-sized businesses, the information an agent would need in order to act well is scattered across a practice management system, a scheduling tool, an inbox, a spreadsheet somebody maintains by hand, and one person’s memory. So the first layer of work is unglamorous and non-negotiable: getting the relevant data and systems into one place the agent can reach reliably, with a clear account of what is authoritative when two sources disagree.
This is where most engagements are actually won or lost, and it is also where most of the real effort sits — which is inconvenient, because it is the part nobody wants to pay for. We would rather say that plainly than discover it together in week six.
The agent layer
This is the layer people picture when they hear the word. It holds the goal, the decision-making, and — the part we insist on writing down explicitly — the enumerated set of actions the agent is permitted to take unsupervised. Book this. Send that. Update this field. Flag and stop, here, under these conditions.
We write that list before we build, and we keep it deliberately short at the start. A narrow set of permitted actions that runs unattended is worth far more than a broad set that everyone is too nervous to switch on. Autonomy you don’t trust is just latency with extra steps.
The oversight layer
“Without constant human supervision” is not the same sentence as “without supervision.” Removing the human from every step makes it more important, not less, that a human can reconstruct what happened afterward and intervene.
So the third layer is logging, an audit trail of what the agent perceived and decided and did, escalation paths for the cases it correctly refuses to handle alone, and unambiguous human authority to override it. In a clinical setting, that layer is the reason the system can be allowed near the administrative shell around care at all. We treat it as part of the build rather than a hardening phase to schedule later, because a system without it isn’t finished — it is merely running.
The standard we hold it to
No vendor lock-in, no $50K consulting engagement. The standard is plain: it should work Monday morning, not in six months.
That constraint does real design work. It rules out any architecture that only makes sense at a scale you don’t have. It pushes toward the narrowest first workflow that actually removes hours from someone’s week, because that is the only version you can stand up and evaluate quickly. And it keeps the layers loosely joined, so the context you have assembled remains yours regardless of what happens to any single component of the system sitting on top of it.
Where this work actually lives
This is the work our agentic-AI practice does: Interactive Intel, a small, Miami-based team that designs, builds and runs production AI agents for SMEs and healthcare practices — lead intake, scheduling, documentation, back-office reconciliation. Every engagement is led by Paul personally and scoped around a measurable outcome.
The entry point is intentionally small: a fixed-price AI Opportunity Scan — one workflow, two weeks, the payback math in writing before you commit to anything larger. It is also the fastest way to find out whether the workflow you have in mind wants an agent at all, or whether it wants something simpler that we would rather build you instead.
Related reading: AI for medical practices · AI consulting for small business