In my last post, I wrote that agents can write code, but we still own the system.
\nI meant that.
\nBut I also kept thinking about the practical part.
\nWhat if the agent did not have to stop when I close my laptop?
\nWhat if it had a real place to work?
\nNot a disposable sandbox that wakes up, changes three files, and disappears.\nA persistent environment where several agents can investigate tickets, run tests, write documentation, and keep moving work forward.
\nThat is what I am building now.
\nNot an autonomous company in a box.\nNot a robot CTO.
\nMore like a small engineering workspace that happens to have agents working in it most of the time.
\nThe idea is pretty simple.
\nThe server is the home.\nThe workspace is the desk.\nJira is the inbox.\nGitHub is the paper trail.\nSlack is the window into what is happening.
\nThis is the rough loop in my head:
\nThat last part matters more than it sounds.
\nIf an agent cannot resolve a ticket after a reasonable number of attempts, I do not want it to keep having an existential crisis in the terminal for six hours.
\nI want it to collect what it learned, create a GitHub issue with the evidence, link it back to Jira, and move on.
\nAt least then a dead end becomes useful work.
\nI was reading this great look inside Anthropic, and it made the difference very clear.
\nPeople there reportedly run several agents in parallel all the time. Token usage is not treated like a personal budget. One large rewrite used 64 parallel agents and around $165,000 worth of tokens at API price.
\nThat is a pretty wild picture of where this can go.\nIt is also very much not my situation.
\nI do not have unlimited tokens.\nMost teams do not.
\nSo I do not want to copy the surface-level behavior and run ten agents on every tiny ticket just because an AI lab can.\nFor me, every agent run has a cost. Context has a cost. A retry has a cost. Even a bad plan has a cost when three agents spend an afternoon following it.
\nThat changes the design.
\nMy system needs to get good at deciding what not to run.
\nA tiny, well-defined bug might get one implementation agent and one verifier. A larger investigation might get a short, capped research pass before anyone edits code. A vague ticket should come back with questions, not consume the monthly budget trying to guess what somebody meant.
\nThe goal is not maximum agent activity.\nThe goal is the highest amount of useful, verified work per dollar and per unit of human attention.
\nI would start way smaller than people expect.
\nFirst, I would create one persistent machine with access only to the repositories, credentials, and services it genuinely needs.\nNo production database access by default.\nNo long-lived admin keys sitting in a folder because “the agent needs them.”\nNo direct path from a Jira ticket to production.
\nThen I would give every task its own isolated worktree or container.
\nThis matters because agents are fast, but they are also very enthusiastic.\nIf three agents are all changing the same branch, you do not have a multi-agent system.\nYou have a group project with no adult in the room.
\nEach workspace should have:
\nThen I would add a small orchestrator. It does not need to be magical. It just needs to keep things moving.
\nIts job is to:
\nThe orchestrator should be boring.\nThat is a compliment.
\nI do not need it inventing a new architecture at 3 a.m. I need it to keep track of work, protect the boundaries, and make the next decision obvious.
\nI do not think one general-purpose agent should own the whole loop.
\nFor a small system, I would use roles like these:
\nThey do not need fake personalities or a weird little org chart.\nThe point is to make responsibility clear.
\nThe planning agent should not quietly approve its own guess.\nThe implementation agent should not decide that failing tests are somebody else's problem.\nAnd the triage agent should not create a GitHub issue that says only: “agent got stuck, please help.”
\nThat issue needs to be useful to a human.
\nEvery pull request should also get a GitHub Copilot review.
\nThat gives the system a fresh set of eyes outside the implementation context. The agent that wrote the code is usually very good at explaining why its own choices make sense. A reviewer is useful because it can push back.
\nCopilot review is not a magic green stamp. It is another quality gate. Comments need to be addressed, tests still need to pass, and a human still owns the merge decision when there is real risk.
\nThis is the workflow I want to try.
\nA Jira ticket enters the system only when it is marked as safe for agent work.\nMaybe it has a label like agent-ready, clear acceptance criteria, and no production or security risk.
The planner turns that into a task. The implementation agent works on it. The verifier checks the result.
\nIf everything passes, the system opens a pull request, requests a GitHub Copilot review, and posts a short summary back on the Jira ticket:
\nIf the agent fails, it gets a limited retry with fresh context. Maybe another agent reviews the failure before it tries again.
\nBut retries need a limit.
\nAfter that, the triage agent creates a GitHub issue and links it to the original Jira ticket. The issue should include:
\nThen Jira can move to something like Needs Human Decision instead of pretending the work is still actively progressing.
That is a small detail, but I think it changes the whole feeling of the system.
\nThe agent is not hiding failure.\nIt is packaging failure so the team can act on it.
\nI do not want to spend my day refreshing Jira, GitHub, and some server dashboard just to see whether the agents are doing anything useful.
\nSo the system should send useful updates to Slack.
\nNot every tool call. Not every thought an agent has. That would get annoying immediately.
\nI want updates for the moments that change the state of the work:
\nEach Slack message should link back to the Jira ticket, GitHub pull request or issue, and the relevant run summary.
\nThat is enough for me to understand what happened and decide where my attention actually matters. I can open the details when I need them, instead of turning Slack into a live transcript of agents talking to themselves all day.
\nI would put the budget rules directly into the orchestrator instead of hoping everybody remembers them.
\nEvery ticket gets a small initial allowance: perhaps one planning pass, one implementation pass, one independent verification pass, and one retry if the failure is concrete.
\nThe system should stop when it hits the allowance, not quietly keep spending because the agent sounds very confident.
\nFor more important work, I can explicitly raise the budget. That is a human decision, like approving more time for an engineer to investigate a difficult problem.
\nI would also keep a simple scoreboard:
\nThat is how the system gets better over time.
\nMaybe a verifier is catching problems early and is worth its cost. Maybe a certain class of Jira tickets almost always needs product clarification. Maybe two agents are redundant for small changes.
\nWithout that feedback, “always on” can become “always spending.”
\nThere are a few things I would keep human-owned from the beginning.
\nCould an agent eventually help with all of these? Of course.
\nBut “can help” and “should decide alone” are very different things.
\nThe system earns more autonomy through evidence.\nIf it consistently handles a class of work well, we can widen the boundary. If it creates confusing pull requests or repeats the same mistake, we tighten it again.
\nThat feels healthier than declaring the whole engineering process autonomous on day one.
\nSetting up a machine that stays on is not the hard part.
\nThe hard part is making sure the agents have enough context to do useful work without giving them a giant pile of outdated notes, random credentials, and permission to create chaos.
\nContext needs maintenance.
\nThe repository should explain how to run, test, and deploy the project.\nImportant decisions should live somewhere the agent can find them.\nTickets need clear definitions of done.\nAnd the system needs observability just like any other production system:
\nWithout that, you are not running an agent platform.\nYou are just leaving an expensive computer unsupervised.
\nI am not excited because I want to remove people from the loop.
\nI am excited because there is so much valuable work that gets delayed by waiting.
\nWaiting for someone to run the first investigation.\nWaiting for a reproducible bug report.\nWaiting for a branch with the obvious cleanup.\nWaiting for a first pass at documentation.
\nAn always-on agent workspace can make those waiting periods smaller. That is the part I find exciting.
\nI can come back in the morning and review a real pull request, a clear question, or a well-written escalation instead of starting from an empty ticket.
\nThat is the version of agentic work I want.
\nMore momentum, yes.\nBut also more traceability.\nMore experiments, but better boundaries.\nAgents working full time, while humans stay responsible for what the system means and what it ships.
\nMy laptop does not have to be running.
\nI still need to be paying attention.
","timeToRead":10,"frontmatter":{"title":"Building My Own Agent Sandbox","description":"How I am building a persistent sandbox environment for AI coding agents, with a human escalation path when they get stuck","date":"2026-08-21T00:00:00.000Z","updated":null,"slug":"/blog/building-my-own-agent-sandbox","tags":["AI","Engineering","Product","Culture"]}}},"pageContext":{}}, "staticQueryHashes": ["1672341955","2009693873","2077189868","3505212370","3825832676"]}