I run Luminik on my own. The product, the customers, the GTM, and the operating model all live in one head. That works at low scope. It stops working the moment “recurring company work” becomes a real category of its own.
Alfred is my answer. It is a small fleet of role contracts around work that needs to happen repeatedly, with a review surface where outputs land and one founder who still owns every consequential decision. This post explains the public-safe shape: what each role needs to know, what it can produce, and which parts I am preparing to open source.
Recurring company functions and engineering workflows, each with a written boundary.
Drafts, PRs, and digests only. Every ship is a human click.
Context. Action. Output. Evidence. Approval.
The Two Layers
Alfred is not one big agent. It splits into two layers, and the split matters because it lines up with how a real company is actually built.
| Departmental layer | Engineering workflow layer | |
|---|---|---|
| Maps to | Functional roles in a company | Tasks inside the engineering function |
| Boundary | Company work that should recur without being remembered manually | Code work that needs isolation, review, or cross-repo coordination |
| Cadence | Scheduled or event-triggered, with exact timing kept private | Triggered by reviewable engineering work, with exact routing kept private |
| Output | Briefs, drafts, digests, summaries | PRs, comments, alerts, status posts |
| Guardrail | Draft and summarize. Do not publish, send, pay, merge, or deploy. | Open reviewable work. Do not approve, merge, or deploy on its own. |
Layer One: Six Departments
Each department is the agent equivalent of one recurring job I would otherwise have to remember manually. The contract is small: read approved context, prepare reviewable output, and surface the decision without taking it.
Chief of staff
Personal assistant
Turns scattered operational context into one reviewable brief. The point is not automation for its own sake. The point is reducing the chance that small coordination work disappears.
Content
Writer
Reads the voice rules and recent real writing before drafting anything. Output includes the post body, distribution notes, and a short proof check. Posting still happens by hand.
Community
Listener
Filters signal from public spaces where solo founders and B2B operators talk. The output is a short source-linked digest, not a feed to keep refreshing.
Sales
SDR
Turns customer and prospect context into a small set of suggested next moves. Sales is where the temptation to automate too much is highest. Replies still need founder judgment.
Finance ops
CFO
Catches small finance drift before it becomes founder debt. The useful output is a checklist I can verify, not an action taken on my behalf.
Product ops
SRE plus CS
Watches the parts of the product customers feel and turns merged work into release-note drafts. It reports and proposes. It does not mutate production.
Layer Two: Engineering Workflows
Engineering is dense enough that the role contracts split again. Each one owns one slice of the engineering function: coordination, implementation, tests, monitoring, review, and notification. The public lesson is the boundary, not the private dispatch wiring.
Alfred
Cross-repo coordinator
The coordinator for features that touch more than one repo. Its job is to make contract drift visible before implementation work spreads.
Lucius
Feature development
The implementer. Reads the repo’s instruction file every time, then opens a branch for review. Stays inside one repo by design so contract changes do not sneak in.
Bane
Test coverage
Looks for tests that would catch a real regression. Coverage for its own sake is not useful; reviewable risk reduction is.
Oracle
Production monitor
Turns health signals into prioritized findings with evidence. When nothing is wrong, it stays quiet. When something is wrong, it makes the next human review faster.
Ra's al Ghul
Code review
The separate review voice. It cares about correctness, security, data integrity, and concurrency. It comments. It never approves its own work.
Bat-Signal
Review notifier
The thinnest role in the fleet. Its job is to make review work visible in one place without adding another analysis layer.
The public lesson is the contract: approved context, source-linked answers, and a human gate before any decision changes the company.
The Five Questions a Role Has to Answer
Before any role goes live, it has to answer five questions in writing. The questions live as the role’s instruction file. If any answer is vague, the role is not ready.
- What context can it read? Specific files, repos, public docs, and approved private notes required for the task.
- What action can it take? Search, summarize, draft, open a PR, or post to a review surface. Never publish, send, pay, merge, or deploy.
- Where does the output land? A pull request, a review note, a markdown file, or a digest. Everything has a path I can find without asking.
- What evidence does it provide? Source links, PR numbers, log lines, file paths. A claim with no provenance is a bug.
- What requires my approval? The line between draft and ship. I want this line obvious enough that a tired founder cannot accidentally cross it.
I use the same five questions to retire roles. Two early agents got cut because I could not write a clean answer to question two. They were doing too much.
What Has Worked
| What works | What did not | |
|---|---|---|
| Code review | Separate reviewer role with no approval power. It catches behavior bugs when my attention is tired. | The implementer reviewing its own work. Same context, same blind spots. |
| Content drafts | Content role reading the voice rules and recent real writing before drafting. | Cached style profile. It drifted the moment the topic changed. |
| Customer support | Personal handling. Reading the thread well enough to approve a draft costs about as much as writing the reply. | Drafting customer-facing replies. Retired the role and the workflow improved. |
| Runtime | Separate always-on environment. Continuity does not depend on my interactive machine. | Recurring jobs on the daily machine. Easy to start, easy to forget. |
Why Solo Builders Need This More
A team has imperfect but real safeguards. Standups, code reviews, review threads, shared calendars, peer correction. A solo builder has none of those by default. The upside is speed. The downside is that every gap routes back to one person.
Agents do not remove the need for operating design. They make operating design more important. When the work gets cheaper to generate, the review queue becomes the scarce resource.
What I Plan to Open Source
Alfred itself will not be open source soon. Role contracts, company context, and private adapters are entangled in ways that would leak company internals. The reusable parts are different. Other solo founders are rebuilding the same scaffolding I did. There is no reason to keep that scaffolding private.
- Role contracts. Markdown templates that answer the five questions for chief of staff, content, sales, ops, and engineering subagent roles.
- Repo instruction templates. Public-safe examples of CLAUDE.md, AGENTS.md, and content-guide files for solo product teams.
- Review rules. The approval gates I use for shipping code, content, sales replies, and finance actions.
- Output formats. Concise summaries, source-linked digests, PR notes, and the morning briefing shape.
- A local runner shape. Enough structure for scheduled jobs and reviewable output without my private adapters.
The release will be patterns first, code second. A solo founder can adopt the role contracts and run them inside Claude Code, Cursor, or any agent harness they prefer. The harness is replaceable. The contracts are what stay.
FAQ
What is Alfred?
Alfred is the public name I use for the agent layer around recurring company work. The important parts are role contracts, approved context, source-linked output, and human approval before anything consequential ships.
Does Alfred ship code or content without my review?
No. Every consequential output is a draft, a pull request, or a digest. The approval gate is explicit so the agent layer never outruns founder judgment.
What runs in production today?
A small set of role-based agents covers recurring company functions and engineering workflows. The public pattern is useful to describe; the private runtime, channels, and schedules stay private.
What might be open sourced?
The reusable patterns: role contracts, repo instruction templates, the five-question gate, output formats, and a small local runner shape. Luminik-specific connectors and customer data stay private.
