You wouldn’t run your SaaS off your laptop.
So why are we doing it with AI?
A lot of the AI automation I see right now still depends on a person sitting in the middle moving information around.
Production throws an error. Someone checks AWS logs, drops them into Claude, figures out what happened and creates a Jira ticket.
Another dev picks up the ticket and has an agent make the change.
Someone reviews it. QA tests it. Maybe DevOps has Codex check the deployment logs over MCP.
Information comes in. A decision gets made. Something happens.
Pretty simple.
Except we keep using humans to connect each step.
We are basically expensive middleware
Most of these systems already have APIs.
AWS knows an error happened.
GitHub knows what changed.
Jira knows what needs to be done.
CI knows whether the tests passed.
The agent can read the code.
So why does someone still need to copy the error out of CloudWatch, explain it to an agent, copy that answer into Jira, then have someone else feed Jira back into another agent?
We’ve automated the tasks without really automating the workflow.
That’s the part I think is going to change.
Where do you actually need a human?
This is probably the harder question.
And every team is going to have a different answer.
Some changes should absolutely require approval. Some companies have compliance requirements. Sometimes the agent is just wrong.
AI output is still pretty meh in plenty of cases.
But it’s getting harder to argue that a human needs to be involved in every step.
For a lot of work, I think you really need one or two human decisions.
Did we understand what we are trying to do?
And later:
Did we actually do it?
Everything between those two questions is fair game.
Even the second one gets interesting when the intent is specific enough.
If the requirement says this endpoint needs to return X, these tests need to pass, latency can't increase past Y and this error should stop appearing in the logs... a machine can check most of that.
Probably better than someone clicking around dev for ten minutes.
Take a boring production bug
Say a service starts throwing a new error.
That error could kick off a job automatically.
Pull the surrounding logs.
Check what deployed recently.
Look through the relevant code.
Figure out the likely cause.
Create a Jira ticket with the useful context already attached.
Then pick that work up, create the branch, make the change, add the test and open the PR.
Deploy it to dev.
Run the E2E tests.
Check the logs.
See if the original problem is still happening.
Nobody has needed to do anything yet.
Maybe that's where a developer gets involved.
They get the issue, the change, the test results and what happened after deployment.
Approve it or don't.
If you want to be more conservative, put a person at the beginning too. Let them approve the diagnosis before spending tokens and changing code.
If you want to hit the gas, make merge approval the checkpoint.
The exact line isn't really the point.
The interesting part is how much work happens before you need that line at all.
The part we're missing is memory
We already have good agents.
Claude Code can work through a codebase.
Codex can work through a codebase.
MCP gives them access to other systems.
The piece I keep coming back to is what happens when one agent is done.
Where does everything it learned go?
Right now the answer is often a chat window.
Or a terminal.
Or Jira after a developer manually summarizes it.
That's not great.
The error, logs, investigation, decisions, code changes, test results and deployment results should live somewhere the next step can use them.
A database would honestly solve a surprising amount of this.
Call it state, context, memory, whatever.
Just stop making a person carry it around.
This is a lot of what I've been thinking about while setting up my automations on SchemaBounce. I started out thinking about where agents do work. Increasingly I think the more interesting problem is the infrastructure that lets them keep doing work without needing somebody to babysit every transition.
Which gets me back to the laptop
You can build almost all of this locally today.
A couple MCP servers, Claude Code or Codex, some AWS access, GitHub, Jira and a little glue code.
I've done versions of it. A lot of developers have.
But eventually you end up with a pretty funny architecture:
Your laptop has become production infrastructure.
Close the lid and your automation is gone.
VPN drops? Gone.
Token expires? Gone.
Someone else wants to use it? Have fun recreating your setup.
Want to know exactly why an agent made a decision three weeks ago? Hopefully you kept the terminal open.
Once these things are actually doing parts of the SDLC, they probably need the same boring stuff we expect from everything else we run.
Hosted somewhere stable.
Scoped credentials.
Persistent state.
Logs.
Retries.
Timeouts.
Versioned workflows.
An audit trail.
Observability.
Not because any of that is exciting.
Because the goal shouldn't be to build the world's coolest prompt running on a MacBook.
The interesting version is when an error can happen at 2 AM, the system can investigate it, put together a fix, prove what it tested, and have something useful waiting for a developer in the morning.
No copy/paste required.
Top comments (2)
I like the boundary you draw around the two human decisions. The danger zone is the glue code between them. Once an agent can read logs, open tickets, patch code, and inspect deploy output, the workflow stops being a chat prompt and starts being a production system.
That is where I want boring controls. A written task, scoped credentials, a diff, a test result, and a rollback note. Without those, moving it off a laptop just gives the mistake better uptime.
The memory section is the part I'd underline twice. We run a couple of autonomous collection jobs on our own servers, and the failure that taught us the most wasn't a closed laptop lid - it was state with no representation. One job wrote seven perfectly good records, hit a non-fatal warning, exited non-zero, and booked its own completed work as "failed, retry later." The exit code was the only memory the system had.
Your line "want to know why an agent made a decision three weeks ago? Hopefully you kept the terminal open" is the whole problem in one sentence. A chat window is memory with a TTL of one session.
One gentle pushback on "a database would honestly solve a surprising amount of this": half agree. A database solves writing state down; it doesn't solve the next agent finding it. Full disclosure, this is the problem I build on (memory for coding agents, over MCP), and the hard part has never been storage - it's that an error and the fix that lands three weeks later share almost no words, so similarity search alone won't connect them. You need the link stored as a link.
Question back: in your 2 AM scenario, where does the investigation trail go - into the ticket, or somewhere the next investigation can query it?