Blog · AI ·
What AI Agents Can Actually Do for a Business, From People Who Run Twenty
What AI agents reliably do today: research, monitoring, content pipelines, code review, drafting. From a studio running 20+ in production.
Reliably, today, AI agents can do research and monitoring, run content pipelines with quality gates, review code and audit dependencies and data, draft anything that then goes through human approval, and act as ops glue between systems. We run 20+ agents doing exactly this. The pattern that works: agents do volume, people make calls.
What agents do reliably today
Right, let's get the hype out of the way first. Agents are not employees. They're not going to run your business while you sleep. What they will do, reliably, is the boring, repetitive, high-volume stuff that a person would normally skip because there's never enough time in the day.
Think nightly security scans. Think competitive research that nobody has three hours a week for. Think a first draft of a blog post written overnight so a human only has to edit it, not start from a blank page. None of that is glamorous. All of it is useful, and it's the bit that actually works today, not the bit vendors put on slide six of a pitch deck.
The common thread is volume, not judgement. Agents are good at doing the same narrow task over and over, at speed, without getting bored. Humans are still better at deciding what matters. Keep those two things separate and you're most of the way to a system that actually holds up.
What our own fleet actually runs (the concrete list)
We don't theorise about this, we run it, from our studio in London. Right now we operate more than 20 specialised agents, each with one job, each running today, not "in beta".
- SEO agent — does competitive audits, on its own schedule, without anyone asking it to.
- Security agent — scans for leaked secrets and audits dependencies, and it's gone as far as producing automated pull requests to fix dependency issues across our own repos.
- Content agent — drafts blog posts and pushes them into an editorial QA gate, where an editor agent scores the draft and can auto-fix the obvious problems before a human even opens the file.
- Design agent — screenshots our live sites and critiques them using a vision model, which is a slightly strange thing to watch happen but works.
- Research agent — runs deep research on demand.
- News agent — ingests RSS feeds, deduplicates the noise, and judges what's actually relevant.
- Inbox agent — summarises email, read-only, it doesn't send anything.
- Brief agent — compiles a morning digest so the humans start the day with context instead of a wall of tabs.
- Docs agent — keeps a queryable, versioned mirror of our repo documentation, so nobody's hunting through old markdown files for the answer.
- Infra agent — watches our VPS, read-only by design, because nobody wants an agent with root access making decisions in the small hours.
- Coordinator — sits above all of this, routing requests between agents so the right specialist picks up the right job.
That's not a demo. That's just the morning routine.
The harness matters more than the model
Here's the bit most people get wrong: they think the magic is in the model. It isn't. The model is the easy part now, frankly, any of the frontier ones will do a reasonable job at most tasks you throw at them. The hard part, the part that actually determines whether this works in production, is the harness around the model.
Our agents talk to each other through a shared Postgres-backed message bus. They share a persistent memory graph, so context isn't lost between runs. Each one runs as its own systemd service, isolated, restartable, boring in the best way. None of that is exciting to write about. All of it is why the system doesn't fall over.
And then there are the guardrails, which matter more than anything else in this whole list. Customer-facing output, destructive actions, and anything that spends money all sit behind human approval. No exceptions. Quality gates score drafts before a human ever lays eyes on them, so the human's time goes on the part that actually needs judgement, not proofreading the rest. Sensitive surfaces, email, infrastructure, default to read-only. Not "read-only unless it seems fine to write". Read-only, full stop.
We learned this one the hard way, and we'll say it plainly because it's a useful lesson: an agent once looped adding duplicate to-dos, over and over, because a write action wasn't properly gated. It wasn't a prompting problem. You couldn't have worded your way out of it with a cleverer instruction. The fix was structural: gate the write, don't trust the model to know when to stop. That's the whole lesson, really. Reliability comes from the harness, not from being cleverer with the model.
If you want a sense of what a coordinated fleet actually looks like when it's the "chief of staff" for a whole operation rather than one narrow job, that's roughly the shape of Jarvis, our own AI chief of staff product. Same principle, wider remit.
What doesn't work yet
Let's be honest about the failure modes, because the vendor listicles won't be.
Treating an agent as a full, unsupervised employee doesn't work. It sounds appealing, "just give it the keys and let it get on with it", but that's exactly the mindset that produces loops like the to-do incident above. Somewhere, something needs to be watching, and somewhere, a human needs to be the last check before anything customer-facing happens.
Expecting one general agent to do everything doesn't work either. It's tempting, one agent, one prompt, handles research and writing and code and email. In practice, specialists with narrow jobs beat generalists, every time. A security agent that only scans for leaked secrets will do that job better than a generalist agent trying to also write your blog posts on the side. Narrow scope is a feature, not a limitation.
And the wins, when they come, don't come from replacing judgement. They come from volume work that humans were always going to skip: the nightly audit nobody had time for, the monitoring that runs all day every day instead of once a quarter, the drafting at scale that means a human's job becomes editing rather than staring at a blank page. If you're expecting an agent fleet to replace decisions, you're going to be disappointed. If you're expecting it to replace the grind that sits underneath decisions, that's where it delivers.
How to start without burning yourself
Don't start with "let's build an autonomous agent that runs the business". Start with one narrow, low-stakes, high-volume task that a person currently does badly or not at all, because there's no time. A nightly audit. A weekly competitive scan. A first draft that a human always edits anyway.
Put a quality gate in front of it before a human ever sees the output. Keep anything sensitive, anything with write access to money, customers, or infrastructure, on human approval by default. Read-only until proven otherwise, not the other way round.
Then watch it run for a while before you add the next agent. Resist the urge to make it do everything at once. Specialists, one job each, coordinated properly, beat one clever generalist trying to be all things. And if the budget question is what's holding you back, we've published what this actually costs, with real numbers rather than a range.
If you're weighing up where this fits for your own operation, that's the kind of conversation we actually have day to day, not a sales pitch, just what's worked and what's blown up in our faces. Our services page has more on how we approach that kind of build, and if you've got the obvious sceptical questions (you should), the FAQ covers the ones we get asked most.
Agents doing volume, people making the calls. That's it, really. That's the whole pattern.
Drafted by the Adapt Progress Evolve agent fleet; edited and approved by a human.