Recently, I was talking to a friend who, much like the rest of the world, has started using AI extensively at work to create agents even though she's not a software developer or from a technical background.
She has been experimenting with Claude a lot, building useful workflows for herself and her team, and getting increasingly excited about what these systems can do.
At some point, our conversation moved onto the work I've been doing around agentic systems: agent architectures, context engineering, memory, orchestration, sub-agents and frameworks such as Strands Agents.
And her reaction was:
Why do you need all of that? I'm already creating agents.
"Great question", I thought to myself.
And what made it particularly interesting was that I'd heard almost the same question from the opposite direction.
After giving a talk about agentic architecture and building harnesses with Strands Agents SDK, a junior developer came up to me and asked:
What's the point of all of this? Why can't we just use Claude for everything?
Two people approaching the subject from completely different directions had arrived at the same question.
And I think that question exposes something important about where we are with agents today. We are using the same word "agent" to describe two very different activities with very different use cases.
The way I see it, there is a big difference between creating agents and engineering agents.
Agent Creation vs. Agent Engineering
Applications such as Claude, ChatGPT, Amazon Quick and others increasingly allow people to create surprisingly sophisticated agentic workflows without building the underlying infrastructure themselves.
There is still a learning curve, though. You need to provide instructions and give the system knowledge and context in a way that produces results that are within expectation (and, hopefully, without hallucinations!). You may also need to learn about tools, set up integrations, schedule work or even create subagents so multiple pieces of functionality can work together.
From the user's perspective, they have created an agent. And indeed they have! But when a software engineer looks at the same system... they see something different.
They see an application providing a highly abstracted, opinionated agent runtime operating as a black box. You have little control over how execution happens, how context is assembled and maintained, how the system scales, or even where memory lives, among other architectural concerns.
As an application user, you are creating an agent inside somebody else's agentic architecture.
And that's not a problem. In fact, this could be exactly what you need!
Developers and software architects make trade-offs between abstraction and control all the time. We don't choose the lowest-level technology simply because it gives us the most control; we use abstractions because they remove decisions we don't want to make and complexity we don't need to own.
The same principle applies here. If Claude gives you everything you need to create an agent, why wouldn't you use it?
As usual with system design, the important thing is understanding the trade-offs. The abstraction works because somebody else has made a set of architectural decisions for you. If those decisions suit your requirements, then awesome. If they don't, you may need to take ownership of some of them yourself.
That's where I find the distinction between Agent Creation and Agent Engineering useful.
For me, three things make that distinction particularly clear.
Is the agent a feature or a component?
This is perhaps my favourite way of thinking about the distinction.
Let's say I create an agent in Claude to research holidays for me. It knows my preferences, researches destinations, compares options and perhaps uses tools to build an itinerary. It could be incredibly sophisticated... but Claude is still the application. I go to Claude, interact through Claude's interface and rely on Claude's infrastructure to make everything work.
My agent is a feature of an application I'm using.
Now imagine I want to offer that same experience through my own travel website. A customer comes to my application and asks for a holiday; somewhere behind the scenes an agent researches flights and hotels, applies their preferences, interacts with booking systems and returns the result.
The capability sounds almost identical, but architecturally something fundamental has changed. The agent is now a component of a system I'm building.
Suddenly I need to decide where it runs, how my application communicates with it, how it scales, how it authenticates against other systems, what happens when it fails, how it fits into traditional application flows, and how I observe what it's doing. The AI is no longer the destination; it's now part of the system I'm responsible for.
That's very clearly Agent Engineering.
The point is really about ownership. If an agent is a feature of Claude or another application, you're limited, quite deliberately, to what that application allows you to do. If your requirements fit inside those boundaries, great. When they don't... you need another abstraction.
Do you need control over the economics?
Another reason you might choose to engineer the agent is cost.
There is a lot of conversation right now about just how many tokens agentic systems can consume, particularly as we build long-running workflows with large context windows, tool calls and multiple agents.
Moving from Agent Creation to Agent Engineering doesn't automatically make any of this cheaper, by the way. Engineering has its own cost, and it would be rather ironic to spend £100,000 in developer time to save £500 in tokens.
What engineering gives you is control.
If you own the harness around your agents, architectural decisions become available that simply aren't exposed when you're operating inside somebody else's application.
You can decide that one task doesn't need the full conversation history, cache an expensive result, retrieve memory only when it's relevant, summarize context between steps, or route simpler tasks to cheaper models.
You can start treating context and tokens as resources that you deliberately engineer.
There's a much larger conversation here around context engineering, but that's a story for another post. For now, the important point is that the abstraction determines which levers are available to you.
If you don't need those levers, there's little value in taking responsibility for them. If the economics of your system mean you do, Agent Engineering gives you that control.
Do you need to own where your data goes?
Then there is a question that tends to become important very quickly in enterprise environments: where does everything actually live?
When I create an agent inside an application, I'm accepting that application's architecture and its mechanisms for handling context, state, memory, integrations and data. Again, that may be completely acceptable.
But what if particular data cannot leave a certain environment? What if I need to know exactly where long-term memory is persisted, control which model receives which information, maintain my own audit trail, or guarantee that certain data never crosses a particular boundary?
Now the black box really matters.
This is partly a compliance question, partly a data ownership question and, yes, partly a vendor lock-in question. The more behaviour, knowledge and state I build around one application's abstractions, the more dependent I become on that platform's capabilities and constraints.
But vendor lock-in isn't, by itself, a reason to engineer everything from scratch. We accept varying degrees of lock-in throughout modern software architecture because managed abstractions can provide enormous value.
The question is simply whether that trade-off is acceptable for the requirements in front of you.
So... Can't We Just Use Claude For Everything?
A useful spreadsheet can eventually become an application, but that doesn't mean the spreadsheet was a mistake. It may have been exactly the right abstraction for the problem at the time, and it may even have helped us understand the problem well enough to know what was worth engineering later.
I think Agent Creation and Agent Engineering should be seen in much the same way: not as levels on a maturity ladder, and certainly not as a journey where every agent should eventually become an engineered one, but as different architectural choices about how much of the underlying system we need to own. We might happily create an agent inside Claude for one task while engineering another from the ground up, perhaps even within the same system.
Sometimes an agent created inside Claude, ChatGPT, Amazon Quick or another application will remain there because it does everything we need. Sometimes our requirements will mean taking ownership of the architecture ourselves and we'll find ourselves reaching for Strands Agents SDK or another agent harness.
And perhaps the next time someone asks me, "Why can't we just use Claude for everything?", my answer will simply be...
You can! For as long as its decisions are compatible with yours.**
Top comments (0)