How to Get an AI Agent to Actually Do Work For You

The short answer: an AI agent does real work when it has four things - somewhere to keep state between runs, tools it can actually call, limits on what it may change, and a record you can check afterwards. Without them it can only describe the job.

Most people's experience of AI agents is this. You describe a job. The agent explains the job back to you, beautifully, in bullet points. You still do the job.

The gap is not intelligence. The models are already good enough for most ordinary work. The gap is that a model in a chat window has nothing to work with. It cannot remember what it did yesterday, it cannot touch the systems where the work lives, and nobody has told it what it is allowed to do.

So it gives advice, because advice is the only thing it can produce. Here is what has to be true before an agent does work instead of describing it.

1. Somewhere to put things

An agent with no memory starts from zero every time. That is fine for a question and useless for a job.

Real work accumulates. Which leads have been contacted, which invoices are still unpaid, which tickets were already answered and how. If the agent cannot read that back, it will redo work, contradict itself, or ask you the same question every morning.

This is a database, not a longer prompt. A prompt is what you tell it this time. A database is what remains true between runs.

The practical test: if you asked the agent "what did you do last Tuesday", could it answer? If not, it is not doing a job. It is doing a demo repeatedly.

2. Things it can actually touch

An agent that can only talk produces text for you to paste somewhere. That is not delegation, that is dictation.

For it to do the work, it needs real connections: the ability to read a record, write a record, send the message, create the file, update the status. Not a description of the action, the action.

This is what MCP is for. An MCP server gives an agent a set of tools it can call directly, and the agent can see the result of calling them, which matters more than it sounds. An agent that cannot see the result of its own action cannot tell whether it worked. It will report success either way.

The practical test: when the agent says it did something, can it show you the thing it changed?

3. Limits on what it may do

The reason most people do not give agents real access is the obvious one. An agent that can update a record can also delete the wrong one, at speed, across a thousand rows, while you are at lunch.

The answer is not to withhold access. It is to shape it.

• Separate reading from writing. Most useful jobs are mostly reading: find, check, summarise, flag. Give the agent broad read access and narrow write access, and the blast radius collapses.
• Scope it to its own data. An agent working on one customer's account should not be able to see another's. Enforced in the database rather than in the instructions, because instructions are suggestions.
• Keep destructive actions out of reach. Deleting, refunding, sending to everyone. Let the agent prepare these and let a person approve them.
• Keep the keys off the client. Anything running in a browser can be read by whoever is using that browser.

For the technical version of this, see How to Give an AI Agent Database Access Safely.

4. A record you can check

An agent that works unsupervised is only useful if you can audit it afterwards. Not a chat transcript, a record: what it did, when, to which record, on whose behalf.

Without that, the first time something looks wrong you have to stop trusting all of it, because you cannot tell which part went wrong. Teams usually abandon agents at exactly that moment, and the agent was often fine.

Pick the right first job

The most common mistake is starting too big. "Run our support" fails. "Draft a reply to every ticket that matches these five known issues, and leave the rest for a human" works.

Good first jobs look like this:

• It happens often enough to be worth automating, several times a week at least.
• It follows rules you can write down. If you cannot explain the decision, the agent cannot make it.
• The cost of getting it wrong is low, or a person checks before anything is final.
• It has a clear finish. You can tell whether it was done.

Bad first jobs are the ones where the work is mostly judgement, or where the rules live only in one person's head, or where a mistake reaches a customer immediately.

What this looks like end to end

Say the job is: when a new enquiry comes in, work out which service it is about, check whether we have dealt with this company before, draft a reply, and flag anything unusual for a human.

The agent needs the enquiry, which comes from a connected tool. It needs the history, which comes from a database it can query. It needs to write the draft somewhere, which is a write it is allowed to make. It needs to flag the unusual ones, which is a status change. And it needs to leave a record of each one, so that on Friday you can read down the list and see whether it has been getting it right.

Every one of those four requirements shows up in a job that simple. Which is why "we gave it a prompt and it did not work" is usually not a model problem.

Where it goes wrong

• No state. The agent repeats work or asks you things it already asked. Fix the memory before blaming the model.
• No verification. The agent reports success because nothing in its loop could tell it otherwise. If it cannot read back what it changed, it is guessing.
• Too much permission. It works for three weeks and then does something expensive. Narrow the writes.
• Too little permission. It cannot finish anything, so you end up doing the last step every time, which is worse than doing all of it.
• No record. Something looks wrong, you cannot tell what, you turn it off.

What to do this week

1. Pick one job that happens at least weekly and that you can describe in rules.
2. Write down what the agent needs to read, what it needs to write, and what it must never touch.
3. Give it somewhere to keep state, so it knows what it has already done.
4. Give it real tools for the reads and the writes, and nothing for the destructive actions.
5. Run it for a week with a person checking the output, then widen it.

Butterbase provides those four pieces as one thing: a Postgres database with per user access rules, authentication, file storage, serverless functions, and an MCP server so agents can act on it directly rather than describing what they would do. But the shape of the problem is the same whatever you build it on. An agent that can remember, act, be limited, and be checked will do real work. One that can only talk will only talk.

Related reading: Why Agent Pilots Stall and Backend for AI Agents.

Frequently asked questions