A solo founder loses time in small places. You reopen the same pull requests. You check the same issue list. You read the same logs twice because you forgot what changed overnight. You carry little pieces of the company in your head until they start bumping into each other.
Alfred exists to reduce that waste. It turns repeated work into the things I can actually use: a plan, a summary, a draft, a PR note, or a short list of decisions.
The screenshots in this post are real examples from my Alfred Slack channel. I am using them because they show the shape of work I want from agents: concrete, bounded, sourced, and waiting for a human decision.
Each role gets a narrow task it can repeat without inventing new authority.
The work lands as plans, digests, drafts, PRs, or notes I can inspect.
A claim with no file, link, PR, issue, or log line is treated as a bug.
What Alfred is
Alfred is my public name for a group of named agents around Luminik and my own work. Some act like company functions: chief of staff, content, sales, finance ops, and product ops. Some sit inside engineering: planner, implementer, reviewer, health checker, and notifier.
The names can be playful. The job descriptions have to be boring. Every role has to answer five questions before I trust it with repeated work.
- What can it read? Specific repos, files, public docs, approved notes, or logs required for the job.
- What can it do? Search, summarize, draft, open a PR, comment, or post a message for me to read.
- Where does the work show up? A pull request, a review note, a markdown file, a Slack message, or a digest.
- What evidence does it provide? Source links, PR numbers, issue numbers, log lines, file paths, or screenshots approved for public use.
- What requires my approval? Anything external, irreversible, expensive, customer-facing, or reputation-bearing.
If an answer is fuzzy, the role gets smaller. If the role cannot get smaller and still be useful, I delete it.
A job description is different from a prompt
A prompt asks a model to do something right now. A job description tells the agent what it owns, what it may read, and where the work should go. That distinction sounds minor until the work repeats.
| Prompt | Job description | |
|---|---|---|
| Job | A request written for this moment | One repeated job the agent can do again |
| Sources | Whatever the chat currently contains | Named files, repos, notes, tools, and source limits |
| Output | An answer in the chat | A summary, evidence, recommendation, and next action |
| Permission | Often implied by the instruction | Written down before the role runs |
| When it fails | The answer sounds plausible | It takes action when it should have asked |
What I want back
I do not want long agent transcripts. I want something I can inspect quickly. If the plan is good, I can approve it. If the summary is weak, the gap should be obvious.
This is the part I care about most. A good summary makes the next decision easier without pretending Alfred owns the decision.
Why I run it on real work
Agent demos often look impressive because the task is isolated. Company work is messier. The answer depends on old decisions, repo conventions, customer language, investor-safe wording, product limits, and what changed yesterday.
A single chat window cannot hold that for long. Alfred makes repeated work easier to run: one role for the job, one source list, one format for the answer, and one approval path.
This matters more when you are building alone. A small team has imperfect guardrails that still help: another person in the PR, a teammate who remembers a customer call, a manager who asks why the task matters. A solo founder has speed and silence. Alfred gives me a way to replace some of the reminders without pretending I have replaced the judgment.
How the engineering side works
Engineering is where Alfred became most concrete first. Luminik has separate repos for backend, frontend, mobile, data acquisition, specs, integrations, and agents. A feature often touches more than one of them. The failure mode is obvious: one repo moves, the others drift.
That is why I split the engineering work into named roles. Batman coordinates multi-repo work. Lucius and Robin can take bounded implementation tasks. Ra’s al Ghul and Bane are useful as reviewers and pressure-testers. Nightwing watches the status and turns changed work into summaries.
Batman
Multi-repo coordinator
Names the repos, order, risk, and acceptance checks before implementation spreads.
Lucius
Implementation
Turns one scoped task into code I can inspect through a normal PR.
Ra's al Ghul
Review
Looks for behavior, security, data-shape, and integration risks from a separate context.
Nightwing
Status and health
Turns the changed work into a short summary so I can see what needs attention.
The names are less important than the separation. The coordinator should not quietly become the implementer. The implementer should not be the final reviewer. The reviewer should not merge. The status role should not turn a weak signal into a decision.
Slack is where Alfred reports
I use Slack because it forces compression. The message has to be readable. It has a timestamp. It can link out to GitHub, logs, docs, or a draft. It can sit next to my approval instead of being buried inside a long agent transcript.
It also gives me a record. A normal morning summary tells me which agents ran, which PRs opened, which PRs merged, and which issues need attention. I can still go to GitHub for the full truth. Slack tells me where to look first.
What has worked
| Works | Breaks | |
|---|---|---|
| Job size | One recurring job with a written boundary. | A general helper that can drift into any task. |
| Engineering | Separate planner, builder, reviewer, and status roles. | One agent doing the work and grading its own work. |
| Content | Drafts grounded in voice rules and recent real writing. | A cached style profile that slowly becomes generic. |
| Sales | Suggestions and notes I can review before any human receives them. | Outbound or replies leaving the system without my approval. |
| Support | Personal handling when the relationship matters. | Drafting customer-facing replies when reading the thread costs as much as writing the answer. |
Sales is important here. I like agents for preparation: summarizing context, finding the last conversation, reminding me what a buyer cared about, and drafting a next step. I do not want them to pretend they can own the relationship. A founder-led sale depends on hearing the buyer’s world clearly. If an agent removes that contact, it is hurting the company.
This is also where Rob Snyder’s demand-side thinking fits my own experience. The job is to find demand that already exists in the customer’s world: a project, a blocked priority, a bad workaround, a to-do item someone is already trying to move. Alfred can help me prepare for those conversations. It cannot manufacture demand, and I do not want it trying.
Where Alfred goes wrong
Alfred gets worse when the role is allowed to be vague. “Help with engineering” is too wide. “Review the changed backend files in this PR for data-contract risk and return comments only” is narrow enough to be useful.
It also gets worse when old context stays alive. A stale spec is dangerous because the agent follows it with confidence. The fix is boring and necessary: update the source docs, make agents cite them, and treat unsupported claims as defects.
The third mistake is too much automation. Some tasks are expensive because they require judgment, taste, trust, or a relationship. Customer replies are the obvious example. If I need to read the whole thread before approving the draft, I may as well write the reply myself.
- Summaries
- Plans
- Drafts
- PRs
- Review comments
- Checklists
- Publish
- Send
- Pay
- Merge
- Deploy
- Commit the company to a promise
The split is deliberately simple. The moment a role needs exceptions to this rule, I slow down and rewrite the job description.
The rest of the company
Engineering is only one part of the system. The same pattern applies to the rest of the company: coordination, content, commercial follow-up, finance checks, and product-health notes.
I use Alfred to keep repeated work from relying on my memory. It can keep the brief warm. I still decide what gets acted on.
| Recurring job | What I review | |
|---|---|---|
| Coordination | Tasks and decisions that get lost when they live in my head. | A short brief with the decision points called out. |
| Content | Ideas, outlines, and drafts that need my voice. | A draft grounded in source notes and voice rules. |
| Commercial follow-up | Buyer context that needs a thoughtful next step. | A suggested move with the last source attached. |
| Finance and ops | Recurring checks across invoices, bank records, docs, and product health. | A checklist, issue, or summary I can verify. |
The OSS version should start small
I want to open-source the reusable parts of Alfred. The private version has company context, customer data, and adapters that stay private. The public version should be useful without any of that.
- Job-description templates. Markdown templates for chief of staff, content, sales, ops, and engineering roles.
- Repo instruction templates. Example AGENTS.md, CLAUDE.md, and content-guide files for a solo product team.
- Review rules. Approval rules for code, content, sales replies, finance actions, and deployments.
- Summary formats. Plans, digests, PR notes, risk summaries, and morning briefs.
- A small local runner. Enough structure for scheduled jobs and work I can review without my private adapters.
A founder should be able to borrow the job descriptions even if they use Claude Code, Cursor, gstack, Codex, or a homegrown harness. The role matters more than the current tool.
Start with one repeated job
If you are building alone, start with one job you already repeat every week. Write the five questions. Keep the answer short and sourced. Keep approval with you.
Run it for a week. If it saves attention, automate the trigger. If it creates another thing to review, delete it. The goal is simple: spend less of your day rebuilding context you already paid to learn.
FAQ
What is Alfred?
Alfred is the public name I use for a set of named agents around repeated company work. It turns that work into plans, digests, PR notes, drafts, and alerts I can review.
Does Alfred ship code or content without my review?
No. Alfred can draft, summarize, open work for review, and ask for approval. Publishing, sending, paying, merging, and deploying stay manual.
What runs in production today?
A small set of named agents covers repeated company jobs and engineering work. Each one has a job, a source list, evidence, and a clear approval rule.
What might be open sourced?
The reusable parts: job-description templates, repo instruction templates, review rules, summary formats, and a small local runner. Luminik-specific connectors and customer data stay private.
