--- title: "Separating agent work from founder work" description: "Why I moved recurring agent work out of my daily workspace, what the boundary controls, and which approvals still stay with me." canonical: https://prasad.tech/blog/dedicated-mac-mini-solo-startup.html source: html generated_at: 2026-05-26T13:56:27.812Z --- [Home](/) / [Blog](/blog/) / Solo builder OS Apr 2026 11 min read Solo builder OS # Separating agent work from founder work Why I moved recurring agent work out of my daily workspace, what the boundary controls, and which approvals still stay with me. I moved Luminik’s recurring agent work out of my interactive development workspace and into a dedicated environment. The decision sounds like an infrastructure detail. It was actually about control: what the agents can read, what they can change, where the work lands, and which calls still need my approval. The argument in one paragraph My daily machine is for interactive work. Recurring company work has a different shape. It needs continuity, current context, and a review path that does not depend on which meeting I happen to be in. Once recurring agent work outgrows the daily-machine model, the answer is less about hardware and more about a separate place to run, memory it can query, and a clear rule: ask before changing anything important. ## Why a dedicated machine | | Founder's daily machine | Company recurring layer | | ------------ | -------------------------------------------------------- | ------------------------------------------------------------------- | | Primary work | Interactive coding, customer calls, multi-file refactors | Documentation drift checks, repo hygiene, scheduled context refresh | | Continuity | Stops when I close the lid | Has to keep running while I travel, sleep, or change contexts | | Authority | Full read and write across personal and company surfaces | Read approved context, draft work for review, never ship silently | | Failure mode | Bad day for me. Recoverable. | Operational drift compounds quietly until something breaks visibly | Two surfaces, two failure modes. Mixing them makes the system easy to start and harder to trust. The separation is an old engineering idea. Build environments and interactive development environments have often been different. The difference here is that the background layer also holds context, answers questions, and routes work to the right tool. The architecture matters because it makes accountability visible. ## The operating shape I think about the setup less as a toolchain and more as an operating shape. Five layers, each with a clear job. Models will change. Agent runners will change. Local and cloud environments will keep trading advantages. The durable part is the split between context, execution, and approval. Five layers I keep visible - **Surface.** A small set of approved ways for me to ask for work or context. - **Context.** Specs, repo instructions, positioning, and architectural notes that agents can query with citations. - **Router.** A resident orchestration process that decides whether a request is a lookup, a draft, a code task, or a scheduled check. - **Worker.** Coding and analysis tools that operate in isolated branches or bounded workspaces. - **Gate.** Human review, pull request review, and explicit approval before anything material changes. The agent operating boundary Ask**Approved prompts**Requests enter through known surfaces. Orient**Queryable context**Specs, conventions, and positioning are cited before work begins. Route**Agent process**The request becomes a lookup, draft, code task, or scheduled check. Work**Bounded workspace**Changes happen in branches I can review, not directly in production. Gate**Human review**I keep the final decision. ## What belongs behind the boundary ### Company memory CLAUDE.md files solve one level of this. Each repo reminds the agent of its own conventions. The scope is a single repo. Company memory is broader: what Luminik calls itself, why the architecture works the way it does, which trade-offs are settled, and which claims are safe to make in public. That context needs to be queryable and cited. A static file is useful for one session. A retrieval layer is better for recurring work because it makes the agent show its sources before it acts. Context discipline for recurring agent work Intent**Specs**What the system should do and why. Reality**Code**What the system actually does today. Voice**Positioning**What the company can safely claim. Rules**Instructions**How agents should behave inside each repo. Check**Citations**Every answer carries its trail back to source. ### Operational visibility Recurring agents should be able to read more than they can change. That one rule eliminates a large class of bad outcomes. The agent helps me notice drift, stale assumptions, and forgotten follow-up. It does not silently mutate infrastructure or product behavior. The first useful run produced a cleanup list: live state that needed reconciliation with declared state, old artifacts from past experiments, reminders I had let sit too long. The fixes were small pull requests. The operating effect was larger. > I want recurring agents to read more than they can change. That rule has prevented more bad outcomes than any model choice. ### Scheduled maintenance Anything that needs to run on a schedule now has a place to run: context refresh, documentation drift checks, repository hygiene, release follow-up. None of these needs autonomy in the theatrical sense. They need consistency, source links, and work I can review. ## What the setup taught me about open source Setup took longer than the READMEs suggested because a few assumptions in the tools were wrong or stale. Normal in fast-moving open-source software. The useful sequence was simple: isolate the symptom, verify it outside my own setup, leave a public trail, and move on with a small local patch. | | Issue | What I did | | --------------------------------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Provider integration regression | An integration change in Hermes Agent broke a path I needed | Reproduced outside local env. Compared with recent upstream changes. Verified the existing community pull request. Maintainer shipped a cleaner fix the same day. | | Prompt assumption that leaked into product behavior | Tool-level instruction inside a platform prompt contradicted intended behavior | Filed an issue with the reproduction and suggested correction. Small bug, revealing one: with agents, product behavior often lives in prompt assembly as much as in code. | | Default that constrained the knowledge layer | A default made one provider path the only practical path | Tested an existing community pull request in a local setup. Left confirmation. Next user got a better default. | Three real upstream encounters during setup. Each one ended with a public trail and a working system. Running open-source tooling that is in rapid development carries a small tax. Source trees change faster than docs. Defaults age out of date. Upstream assumptions lag the services they talk to. The right response is calm reproduction, useful comments, and small reversible patches. ## Separation of concerns The useful part was the boundary itself. Before this change, personal work, interactive development, company context, and recurring agent work all shared the same machine and habits. After the change, I had two places to work: my interactive workspace and the company’s always-on runner. Different context, different permissions, different schedules, different failure modes. The part of agent infrastructure that deserves more attention Autonomy is less interesting than accountability. A recurring agent should have a role you can explain, a boundary you can audit, and work you can review. The quality of an agent system mostly comes from the quality of its boundaries. ## When you have earned the complexity This setup starts making sense once three things are true at once. Agents are producing enough work that review, memory, and follow-up start to blur. Your specs or CLAUDE.md files are authoritative context you update often. And at least one workflow would benefit from running on a schedule instead of when you remember to run it. Before that, a laptop and disciplined notes are enough. The minimum setup, conceptually - **A separate environment.** A machine or workspace whose job is company operations, not personal browsing or interactive development. Boundary matters more than vendor choice. - **Fit-for-purpose models.** Routing, summarization, and implementation are different jobs. Model choice is an architecture decision, not a loyalty program. - **Inspection before mutation.** Default recurring agents toward read, compare, summarize, draft, and open work for review. Writes move through the same approval path you expect from a careful teammate. - **Queryable knowledge layer.** Static instruction files are necessary for in-repo conventions. Cross-session memory wants retrieval, citations, and freshness checks. - **Code is the source of truth.** The agent’s system prompt should say this explicitly. When the knowledge layer disagrees with code, surface the conflict rather than silently picking one. ## Where this is going Luminik, like any company, is a collection of recurring jobs. Keeping docs in sync with code. Reviewing the gap between intent and implementation. Turning customer signal into sharper product decisions. Noticing operational drift. Most of these jobs share a shape: trigger, sources, action, summary, review. The dedicated environment gives those jobs a place to run: always-on runtime, separated context, queryable memory, and scheduled checks that produce work I can review. It is the coordination system a solo founder needs to run a company with the discipline of a larger team. Background agents need bounded context, bounded authority, and work a founder can review. That is the standard I am using for the next version of the setup. ![Prasad Subrahmanya](/assets/images/header/prasad.jpeg) ## Prasad Subrahmanya Builder and operator at Luminik. Built Aura at Bain to $3.6M ARR, co-founded Mainteny through its $2.7M seed, and helped build the initial product and team. [LinkedIn](https://linkedin.com/in/prasadus) [GitHub](https://github.com/prasadus92) [ Back to blog](/blog/) ## Filed under Solo builder OS solo founderAI agentsagent infrastructureLuminik ## Related notes [**Alfred: how I run repeated work as a solo founder**How I use Alfred to turn repeated company work into plans, summaries, draft replies, and pull requests I can review before anything ships.](/blog/alfred-solo-founder-operating-system.html)[**gstack, CLAUDE.md, and founder coordination**gstack formalizes role-based agent work. The harder part is still product rules, cross-session context, and isolated branches.](/blog/gstack-solo-builder.html)[**The real cost of solo product engineering in 2026**The tools got cheaper and faster. The harder work is still product direction, instruction files, review, and knowing what needs a human decision.](/blog/building-alone-in-2026.html)