Inside the room
Throw It Over the Fence: How Trevor Keith Delegates Work to AI Agents
You gave AI a task. Why are you still doing half the work?
You ask an agent to do something. It comes back with a question. You answer. It takes another step. You approve it. Then you check the result, fix a mistake, and explain what to do next.
The agent is working. So are you.
For Trevor Keith, founder and CEO of Solid, that constant involvement is worth examining. Over the past two years, his own process has moved from approving individual code edits to handing agents responsibility for ongoing operations.
He calls it throwing work over the fence: giving an agent a larger goal, enough context to pursue it, and clear boundaries around when to involve you.
Here’s what founders can take from his approach.
Look at how often the agent needs you
Trevor places delegated work along a spectrum:
01
Every step.
You approve each action.
02
Every output.
You review everything it produces.
03
Checkpoints.
You step in at agreed moments.
04
Final result.
It completes the work before coming back.
05
Decisions only.
It brings you the calls that need your judgment.
Different jobs can sit at different points. The useful question is where your involvement helps, and where it simply keeps the work waiting.
Crucially, autonomy can require a lot of instruction. Trevor says his most autonomous system runs on the most detailed instructions he has written.
A thorough brief can reduce the need for a hundred small follow-up conversations. Explain the outcome, give the agent the context it needs, and specify what it should do when something goes wrong.
Start with the messy work that keeps piling up
Some tasks are easy to describe in code. Others depend on a person’s taste or judgment.
Trevor is interested in the work between those categories: reading through inboxes, reconciling messy records, or watching for a change and deciding how to respond. It involves enough ambiguity to make traditional automation difficult, but enough repetition to consume a person’s day.
His slides describe four jobs he has handed over:
01
DevOps.
Deployments and network configuration. He reports no destructive errors and less downtime than before.
02
Bookkeeping.
Operating the accounting software and paying bills. He says an agent also caught a mistake made by his human accountant.
03
Video.
Turning raw clips into content ready to post.
04
Account setup.
Buying eSIMs, setting up phones, and opening accounts.
These are Trevor’s results from his own setup. The useful exercise for another founder is to identify a similarly concrete job: something recurring, time-consuming, and clear enough that you can recognise a good result.
“Help with operations” leaves a lot unresolved. A defined responsibility gives you something you can hand over and evaluate.
Give the agent its own access and real limits
Handing over work becomes much harder when the agent needs to ask you for a login, a payment, or a verification code at every turn.
Trevor’s approach is to onboard it much as he would a new hire.
01
Give it a separate identity.
In his setup, agents have their own accounts, with access appropriate to their jobs. That makes their activity easier to trace and their access easier to revoke independently.
02
Put hard limits in the infrastructure.
If an agent can spend money, the card should have a cap. Its accounts should only expose what the job requires. A written instruction about spending and an enforced card limit serve different purposes.
03
Write the operating rules in plain English.
Explain what the agent can do, how to handle routine situations, and what needs to come back to you.
04
Define the escalation points.
Trevor names irreversible actions, high-stakes decisions, and calls that need his intuition as reasons to involve him.
The handoff includes both permission to act and a clear point at which to stop and ask.
When an output falls short, ask for another pass
A disappointing first result can send you straight back into doing the job yourself.
Trevor suggests trying another response first: ask the agent to investigate further, check its work, or spend longer on the difficult part.
He says newer models have made additional effort more useful in his workflows. His advice is to give the agent room to improve the result before taking the task back.
That is a useful distinction when you’re evaluating a handoff. Did the agent lack the context? Did it stop too early? Did it fail to check something important?
Those questions give you a specific revision to request and a way to improve the instructions for next time.
Keep the work where your perspective matters
Trevor still keeps two areas for himself: writing that another person will read, and raw ideation.
For writing, the agent gathers the information and he writes the words. For ideas, he worries that founders using similar inputs will end up with similar suggestions.
It’s a revealing boundary for someone delegating so much of his company’s operations. He is deliberately choosing where his own thinking belongs.
For your company, that might mean keeping the customer conversation, the creative direction, or the final call on a sensitive message. Deciding what to retain is part of designing the handoff.
Change one part of the company at a time
You don’t have to reorganise the whole business to try this.
Trevor describes replacing individual pieces of a workflow while the rest continues running. A shared CRM agent, for example, could ask a person for information or ask that person’s agent. Each agent can have different permissions, just as people on a team do.
Existing software can stay in the process too. In his bookkeeping example, the agent operates Puzzle. The accounting tool still holds the records, while the agent handles the work around them.
That gives founders a manageable starting point: choose one recurring responsibility and work out what would allow an agent to carry it through.
What to try this week
Choose one task you keep postponing because it is tedious, messy, or never quite finished.
Write a short handoff covering:
01
The outcome.
What should be true when the work is done?
02
The context.
What information and tools does the agent need?
03
The limits.
What access, spending, and actions are allowed?
04
The escalation points.
When must it involve you?
05
The review.
How will you judge whether the handoff worked?
Then look at where you currently step in. Could you move from approving every action to reviewing an output? From every output to a checkpoint?
Trevor’s longer-term ambition is for agents to help decide what deserves his attention. He presents that as the next step he is building toward, rather than something he has already solved.
For now, there is a smaller question worth answering: what is one job you could give a clearer brief and a little more room to complete?
About the speaker
Trevor Keith is the founder and CEO of Solid, which gives AI agents access to computers, phone numbers, accounts, and payment tools so they can carry out work across services.
This recap is based on Trevor Keith’s “Throw It Over the Fence” slides and accompanying speaker notes. Operational results are Trevor’s reported experience. The exercise above applies the ideas from the presentation.
