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.
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 |
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.
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.
Operational visibility
Recurring agents should be able to inspect 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 PRs. The operating effect was larger.
I want recurring agents to inspect 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 PR. 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 PR in a local setup. Left confirmation. Next user got a better default. |
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.
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.
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.
