By Pavan Kumar T V ·
An Agent Is a Job, Not a Service
Series: Part 1 of four on agents, and this one is definitions. Part 2 is the economy, Part 3 is careers, Part 4 is the org.
GGartner went through the vendors selling "agentic AI" this year. Thousands of them use the word. Gartner reckoned about 130 were building anything that deserved it.
That's roughly 1%.
The other 99% aren't frauds. Most of them shipped something real and useful. They put the wrong word on the box, because nobody agreed what the word meant.
I've had this conversation a dozen times this quarter. Founders pitching. Engineers arguing. Solo builders who ship things that work and want to know whether they built them properly. In one group chat, three people used "agent" four different ways in a single thread and nobody noticed.
The question underneath all of it is always the same. What should the base architecture for agents look like in a small application?
I used to start drawing boxes. I stopped, because the answer isn't a box diagram. It's a job description.
We Spent 20 Years Engineering Software to Forget
Look at what every principle you were taught actually optimises for.
- REST: no session on the server.
- Twelve-factor: processes are disposable, share nothing.
- Horizontal scaling: any instance serves any request. Only true if no instance remembers anything.
- Idempotency: same call twice, same result.
- Pure functions, immutable infrastructure, cattle not pets.
Every one of those is a rule about forgetting.
I argued for all of it. I've sat in design reviews and made people pull session state out of a server. I was right then and I'd argue the same case tomorrow for the same systems. State was what broke at scale, and a system that remembers nothing can be restarted, replicated, and reasoned about at 3am.
Then we put a model in the middle of that stack and called it an agent.
Now the most valuable property of the system is the exact thing the stack was built to eliminate.
Statelessness is the first inherited virtue that became a bug.
This is why so many agent frameworks feel thin. They model the agent as a while-loop around a model call. The loop runs, the task completes, the process exits, and everything learned inside it dies at exit because the design has nowhere to put it. We built something that reasons, then threw away the hippocampus at the end of every conversation.
You can't fix that with a bigger context window. A context window is a longer breath. It isn't a memory.
If that sounds like a contrarian take, it isn't anymore. The ICLR 2026 workshop on agent memory landed on the same thing from the research side: memory is the central unsolved infrastructure problem in agentic AI, and the hardest part isn't storage, it's staleness. Three separate teams building agent frameworks have independently converged on the same three-layer split of global, role-scoped, and private memory. Everyone is discovering the same hole.
Say What You Actually Built
One word is doing five jobs. Separate them.
An engine is a deterministic transformation. Rules in, result out. Pricing engine, rules engine, search engine. No identity, no memory, and that's the feature. The same input a year from now produces the same output.
A library is an engine you link into your own process. You own the lifecycle, you hold the context, it forgets you the instant it returns.
An API is an engine behind a boundary with somebody else's team on the other side. Its defining property is that the caller needs to know nothing about it. That's what a contract is for. Stateless by design, because state would make it unreliable for the next caller.
A model is a probabilistic engine. Same input, roughly the same output, no memory of the last call. Non-determinism is not personality. A model that surprises you is still an engine.
A workflow is a graph of those. Orchestration lives in the edges, every node stays dumb. Most things sold as "agentic pipelines" are this. Nothing wrong with it except the name.
An agent is the only thing on that list that is supposed to be different tomorrow because of what happened today.
That's the dividing line, and it beats any capability argument. Everything above it is designed to be unchanged by use. An agent is designed to be changed by use.
engine api model workflow agent
holds context caller caller caller the graph itself
state after a call none none none discarded permanent
100th call better? no no no no yes
can it refuse? no error no no yes, with a reason
can it delegate? no no no pre-wired decides who owns it
who answers for it author owner author author itself, then its owner
So here's the test, and it's one sentence.
Run the same interaction 100 times. Does the 100th go better than the first?
If no, you built a service. Services are supposed to be stateless. That's their job and it's a good job. Name it honestly and move on.
Three Things That Invert
Take the definition seriously and three things you know for certain turn upside down.
1. Context flips direction. An API is engineered so the caller carries all the knowledge. An agent is engineered to accumulate knowledge of the caller. Opposite goals. Wrap a model in a REST route, call it an agent, and you get neither. It can't hold state because the route is stateless. It can't be trusted because the model isn't deterministic. You gave up the virtue of both categories and kept nothing.
2. Version means the opposite thing. An API version is a promise not to change. An agent version is a record of having changed. Same word, inverted purpose. Version an agent the way you version an API and you get one number that never moves while the thing behind it drifts every week.
3. Idempotency becomes a defect. We spent years making sure the same request twice produces the same result. Now ask a colleague the same question twice. The right answer is "you asked me this on Tuesday, here's what we decided." An agent that answers identically the second time just told you it wasn't listening the first time.
That third one breaks your testing strategy, so sit with it.
An engine fails loudly and identically every time. That's precisely why unit tests work. An agent fails the way a new hire fails: plausibly, once, in a way that looked fine in the moment and turns out to have been wrong six weeks later.
You don't catch that with assertions. You catch it the way organisations have always caught it. Read-back, review, escalation, and a record of who decided what.
Which is the real answer to the architecture question. The hard problems here aren't architectural. They're organisational, and we have a few thousand years of practice managing things that are capable, useful, and occasionally confidently wrong.
The Fresher and the Chief of Staff
Two assistants.
One started this morning. The other has been chief of staff to a CEO for ten years.
Same title. Same interface: you ask, they do. Written down as a spec, the two are indistinguishable. You could not tell them apart from the job description, the tool access, or the API surface.
The entire difference is what accumulated.
The experienced one knows what you meant, not what you said. Knows which of the three people named Sharma you meant. Knows you rejected this exact approach in March, and why. Knows that "quickly" means today and "urgent" means you're already late.
None of that was in the spec. All of it is the value.
A profession works because every interaction leaves a deposit. The person isn't executing a function. They're compounding.
Our agent stacks ship the fresher. Every morning. Forever. Then we benchmark the fresher against other freshers and publish the score.
What a Person Has That a Module Doesn't
If the useful definition of an agent is "something that behaves like a person doing a job," then the design checklist stops looking like architecture and starts looking like a hiring plan.
persona who is this, what is it responsible for, what is it not
memory long-term, compartmentalised, survives the process
learning a defined surface where a human can teach it
expertise a real skill set, deep and narrow, not "helpful assistant"
delegation knows what isn't its job and who owns it
teaching can brief another agent, and can brief me
growth the skill set changes over time, and that change is visible
Take those seven and run them against whatever you shipped last month. Score each one yes or no. Most systems I've looked at score 2.
Because two of them are nearly free today:
Persona is a system prompt. Crude, but sufficient.
Expertise is free if you commit to it. A taxation agent, a customs classification agent, a receivables agent, a backend engineer agent. Narrow and deep beats broad and shallow here for the same reason it does with people. Nobody hires a generalist for a compliance filing.
The other five are the work. They're what the rest of this series is about.
Part 2 is the economy. The moment a thing behaves like a colleague, it stops being compared against tools and starts being compared against a salary. That single fact rewrites your pricing and tells you where to build.
Part 3 is careers, for the agent and for you. Something that accumulates for two years is not the entity you deployed, and pretending otherwise is how you get drift instead of growth.
Part 4 is the org. Delegation, teaching, memory you can audit, and the one structural advantage an agent team has over a human team that almost nobody is building for.
The Bottom Line
One line changes most agent designs I see.
If it can't be different tomorrow because of what happened today, you didn't build an agent. You built a service.
Go back and name it honestly. Services are extremely well understood, they're cheap to run, and nobody expects them to remember your name.