The Agent Is the Easy Part
Everyone wants a swarm of agents running their busywork in the background. Having actually built and shipped a pile of them, I can tell you the model was never the hard part — identity, observability, bounded reach, coordination, and knowing what not to automate are. That's the whole game.
Everyone wants the same thing right now: a swarm of agents running quietly in the background, doing the busywork, so you wake up to finished work instead of a to-do list. It's a good dream. I want it too — it's most of why we're building Funal.
But I've spent the last few months actually building these things and running them against real customer data, and I want to be honest about the part the demos skip. The agent was never the hard part.
The model is the easy part. It's good, it keeps getting better, and you can get a jaw-dropping demo out of it in an afternoon. The hard part is everything around the model — and almost none of it is about how smart the model is. Here's what actually turned out to be hard.
An agent that can do things will, eventually, do the wrong thing
This is the one everybody feels and nobody wants to say out loud. The same agent that reads the context perfectly and takes exactly the right action will, on some random Tuesday, confidently do something insane — email the wrong client, overwrite a field, fire off a message that should never have left the building. Not because it's broken. Because it's a model, and models are wrong sometimes.
If that agent has its hands directly on your database and your outbox, "sometimes wrong" is a liability, not a quirk. So the real problem isn't making the agent smarter. It's making sure that when it's wrong — and it will be — the damage is contained.
The way we landed on solving it: the agent decides what to say, never what happens. It reads, it reasons, and it produces a structured result. But the things that actually touch the world — the writes, the messages, the updates — are written by us, ahead of time, and they take the agent's output as their input. The model's entire reach is a typed payload handed to code I wrote. It can hallucinate a bad sentence. It can't invent an action I never gave it.
The judgment is the model's. The blast radius is mine.
Whose login is the agent using?
Here's a question that sounds boring and turns out to be load-bearing: when an agent writes a record or reads someone's email, who is it acting as?
If it just runs as "the system," it has god-mode — read anything, write anything, on behalf of anyone. Convenient right up until it isn't. The right answer, almost always, is that the agent should run as a specific person — usually whoever triggered it — scoped to exactly what that person is allowed to do, with their name on every action it takes.
That's harder than it sounds, because most agent setups have no concept of identity at all. The agent is just... the agent. Getting an autonomous background process to act as a particular human — with their permissions and their audit trail, without that human being logged in, because it's 3am and they're asleep — is real work. But it's the entire difference between an agent that's a member of your team and an agent that's a loaded gun with nobody's name on it.
When it does something weird, can you tell what happened?
An autonomous agent running in the background is, by default, a black box. It did something while you weren't looking. Was it right? You're not totally sure. That uncertainty is corrosive — it's the actual reason most people quietly switch these things back off.
We had one of our agents look completely broken recently — a task that should've taken a minute was taking half an hour. The instinct is to assume the AI went haywire. It hadn't. I pulled up the run log and it told me exactly what happened: it was retrying a write over and over because of a type mismatch I'd introduced. The agent was fine. It was honestly reporting a bug I'd handed it. Five-minute fix.
That only happened because every run records what it saw, what it did, and what failed. An agent you can't read the logs of isn't autonomous — it's just unsupervised. If you're going to let these things run on their own, the unglamorous infrastructure of "what did it actually do" is not optional. It's the thing that lets you trust the rest.
Most of what you want to automate shouldn't be an agent at all
This one surprised me. We built a genuinely capable agent engine, and then I went through everything we wanted to automate for one of our customers and realized most of it shouldn't go anywhere near a model.
"When this field changes, reformat that one." "When a payment comes in, update the total." That's not agent work — that's a rule. Wrapping it in an LLM makes it slower, more expensive, and less reliable than three lines of deterministic logic. The temptation, once you've got the shiny hammer, is to make everything an agent. The discipline is to use the model only where there's real judgment to be made — reading messy context, writing a summary, deciding what's worth surfacing — and to leave the boring deterministic stuff boring and deterministic.
Out of dozens of automations one customer had, a handful genuinely needed an agent. The rest were rules. Knowing which is which is most of the skill, and "make it all agents" is the wrong answer.
A pile of background agents will step on each other
The last one only shows up once you have more than one of them, which is exactly the world everyone's racing toward. The dream is a swarm of autonomous agents. The reality is that a swarm of things all reacting to the same events will, without coordination, do the same work twice and contradict each other.
I hit this head-on last week: I switched on a new agent to handle client onboarding and nearly shipped it — until I found that an existing automation already did that job, better, on the same trigger. Two agents, same event, racing to onboard the same client. Autonomous doesn't mean coordinated. The more of these you run, the more the hard problem stops being "is the agent smart" and becomes "who owns which event, what's the source of truth, and how do they not trip over each other."
So what actually works
Notice that none of those hard parts are about the model. They're about reach, identity, observability, restraint, and coordination — the stuff that doesn't demo well and turns out to be the whole game.
What's worked for us is to stop treating "agent" and "workflow" as a thing you choose between. We run everything on one shape: a few deterministic steps gather the facts, one step lets the model use its judgment and emit a structured result, and then deterministic steps — written by us — take that result and do the consequential things, with a check at the end that it actually worked. The model's judgment is welcome. Its hands are ours. Every run is journaled, runs under a real identity, and can only touch the things we've explicitly allowed.
It's less magical than "a swarm of autonomous agents doing everything." It's also the version you can actually leave running.
The boring parts are the product
The whole industry is racing to make agents smarter. I think that's the wrong thing to fixate on for anyone trying to put one near real work. The model will keep improving on its own — you don't want your safety story to depend on how sharp it happens to be on a given day.
What decides whether you can actually let an agent run in the background isn't how smart it is. It's whether its reach is bounded, whether it has a name, whether you can see what it did, and whether it's even doing work that needs a brain. Get those right and the model can be merely good and the whole system is trustworthy. Get them wrong and it won't matter how brilliant the agent is — you'll turn it off the first time it scares you.
The agent is the easy part. The boring parts are the product.