Everyone's building agents. The ones that survive share a shape.
Spent part of this week reading a V2EX thread where someone argued AI had basically retired the ops role. Write the scripts, run the SQL, sit the 3am deploy window, all of it handed to a bot that works 24 hours and doesn't complain. Bold take. The replies were where it got useful.
One person described an AI ops agent that caught a disk-space alert and, being helpful, cleared the `data` directory. Another said Grok swapped out a TLS cert for them and took the whole thing down. Someone else made the dry observation that AI can't hold the pager because it can't be blamed yet. And then the comment that actually resolved the argument: don't let the model operate production directly. Turn the routine, repeatable work into programs. For everything else, give the model a tool layer, let it only see and change what those tools permit, and keep a human on the dangerous one percent.
That's not a hot take about ops. That's the shape of every agent worth running.
Why the "give it everything" version keeps failing
There's a second thread that rhymes with the first. People comparing notes on personal agents, and the recurring complaint is that they go stale. You wire up a few scheduled jobs, they ping you for two days, and then you reflexively swipe to something else the moment the notification lands. One person put it bluntly: the agent became a beautiful little useless thing.
But the same thread had someone whose setup had run for months. The difference wasn't a smarter model. It was that interesting findings didn't just get pushed at them, they got written into a knowledge base and turned into a discussion summary plus a TODO. The agent produced something durable you could come back to, not a stream of alerts you learned to ignore.
Stack those two signals and you get a fairly clear engineering brief. The model is the easy part. The work is the boundary around it: a small set of explicit actions it's allowed to take, a place to persist what it finds, and a surface where a human reviews before anything irreversible happens. A whistleblowing-system writeup in the same batch made the same point from a different angle. The form was trivial; the hard parts were who's allowed to see what, and how to keep state the system shouldn't be holding from ever existing in the first place. Authorization and persistence, again.
What I'd actually assemble
If I were building this as an independent dev rather than theorizing, here's the layout I'd reach for, and VicroCode happens to cover most of it in one place.
Start with the tool layer, because that's the load-bearing decision. Instead of letting the agent run arbitrary commands, you define each permitted action as its own endpoint and expose it through API Endpoint Hosting and in-platform tool calls. "Read the latest status." "Append a note to report #4821." "Mark this task done." Each one is a narrow, named capability with validation baked in. The agent can only do what you've written a tool for, which is exactly the constraint the ops thread arrived at the hard way. This is the core of real AI agent development: the intelligence is interchangeable, the bounded action surface is the product.
Behind those tools, the logic runs as Python. Parsing, fetching, summarizing, deciding what's worth surfacing, it all lives in a Python backend you host in-platform. Nothing exotic, and keeping it to one language means less glue to maintain. Worth stating a boundary here: the confirmed VicroCode capabilities don't include a built-in scheduler or cron. If you want this to wake up on its own, you'd trigger the hosted endpoint from outside the platform or kick runs manually. The agent, its tools, its storage, and its review screen can all live here; the clock that pokes it does not.
For persistence, split it in two the way the long-running personal-agent setup implicitly did. Structured state (tasks, statuses, an audit trail of every tool call the agent made) goes in SQLite, which you can edit directly when something needs a manual correction. That audit trail matters more than it sounds. When an agent touches anything sensitive, you want a plain record of what it did and when, and it doubles as the "keep a human on the dangerous one percent" mechanism, you read the log before approving the next step. The softer material, the summaries and findings you actually want to search later, goes into a LanceDB knowledge base so the agent can retrieve against past context instead of starting cold every run.
Then the part that decides whether anyone keeps using it: the review surface. A dashboard that shows pending actions, recent findings, and anything waiting on a human yes/no. You can run HTML online for that directly, no separate hosting to arrange. This is where the whistleblowing writeup's point about perceived trust lands, concrete is more convincing than abstract. A screen that says "here is exactly what the agent proposes to do, approve or reject" beats a vague promise that it's all handled. And when a run produces something good, you have somewhere to go read it, which is the whole reason the durable setups didn't end up as beautiful little useless things.
The honest part
I haven't run this specific build end to end, so treat any claim about how reliable or sticky it'd be as unverified. What I'm confident about is the shape, because the evidence keeps converging on it from unrelated directions: ops people watching bots delete things they shouldn't, personal-agent tinkerers watching notifications go stale, system designers realizing the form was never the hard part.
The pattern underneath all of it is the same. Don't buy an agent a skeleton key. Hand it a labeled keyring, write down which doors it opened, and stand at the one door that matters. The model you plug in behind that boundary can change next month, and probably will. The boundary is the thing you're actually building.