Run a one-person company on AI agents
For the last six months I have run a one-person company almost entirely on AI agents, out of a single git repo. Task: For the last six months I have run a one-person company almost entirely on AI agents, out of a single git repo. Not "AI writes my emails." The actual operations. Marketing, sales, CRM, content, outreach, all of it. I did not set out to build a framework. I set out to stop doing admin. But after enough things quietly worked and roughly the same number blew up in my face, a rough framework fell out of it. 10 parts. Each one below has what held up and where it broke, because the where-it-broke half is the part I would actually want to read. I am posting it to get holes poked in it, so if you are building the same thing, tell me where I am wrong. 1. Put the whole company where the AI can read it (context as code) Stop wiring the AI into ten SaaS tabs. It is bad at clicking buttons and good at reading and writing files, so move the company to where it already works well, which is plain files in one repo. Every department is a folder. What held up. The AI went from useless across ten browser tabs to genuinely running things the day it could read and write the whole business as text. Where it broke. The folder gets fat and recall rots (there is a name for it now, context rot). You load context on demand. You do not dump the whole company into the window and pray. 2. A routing brain: one root file, departments as folders with playbooks Each folder holds a plain-English playbook (a CLAUDE.md) with who you sell to, your voice, the rules, the tools it may touch. A root file routes the work: TASK: "find leads and email them" | root CLAUDE.md (the router) | opens the playbooks that own the task v sales/CLAUDE.md + crm/CLAUDE.md (plain-English rules) | agent becomes that department head | does the work | writes the result back into the repo | next task starts with more context, not zero What held up. One generalist agent plus good playbooks beats a fleet of brittle specialised bots for most work, and cross-department tasks route themselves. Where it broke. A single generalist still drowns on genuinely complex parallel multi-step work. That is the only place I reach for subagents, because a multi-agent run costs roughly 15x the tokens, so it had better be worth it. 3. Own the tools that touch your core workflow, and treat every platform as hostile I rebuilt the internal SaaS I was paying for as small apps, each reading one database and one brand kit. A LinkedIn client that drives a real browser session. Its own CLI for Instagram. Google Workspace from the terminal, so an agent can book a meeting or send an email inside a workflow. The platform-facing ones taught me the most, the hard way. Early on an agent fired actions on a social platform in fast batches and the account got suspended. Fully deserved. So the clients now have hard daily caps in code (20 connects, 40 DMs, 80 profile views), run human-paced, and verify every send by counting the message elements before and after, because the compose flow silently changed twice and cheerfully reported success while nothing actually sent. What held up. Own the workflow tools (a session each, zero integration tax), rent the plumbing (database, email, payments, hosting, lead data). Caps in code, not in the prompt. And never believe a platform's own "success", check the DOM changed before you claim you did anything. Where it broke. Trusting the platform's word and moving fast. Both get you blocked or lied to. 4. Give it senses: a nightly Scout, intelligence digesters, inbound monitors, signal farming This is the part people skip, and it is most of the magic. The company perceives the world through a few standing flows: inboxes ----\ CRM --------\ rankings ----> SCOUT (nightly) --> one brief: what moved, what needs you competitors-/ feeds ------/ HN / Instagram / X / a FB community --> digesters --> scored signal + ideas LinkedIn + FB inbox --> hourly monitors --> new reply? --> queue + phone ping buyer-relevant posts --> signal farming (read + like only, 3x/day) --> lead pool all of it --> STRATEGIST --> the day's few highest-leverage moves; tools: custom-built or unnamed agent. Human role: I review on desktop or phone.; limitations: Prerequisites include technical proficiency in Git, file management, and custom tool development. Constraints: Multi-agent runs cost ~15x tokens; single agents struggle with complex parallel tasks. Risks: Platform bans for automation; 'context rot' if files are too large. Integration uncertainty: Platform APIs/UIs change silently, requiring DOM verification. Human approval is required for all outbound actions. Source reliability is secondary (Reddit post)..
Tools
custom-built or unnamed agent
Published on Agent Work Atlas:
Overview
For the last six months I have run a one-person company almost entirely on AI agents, out of a single git repo.
Workflow
For the last six months I have run a one-person company almost entirely on AI agents, out of a single git repo. Not "AI writes my emails." The actual operations. Marketing, sales, CRM, content, outreach, all of it. I did not set out to build a framework. I set out to stop doing admin. But after enough things quietly worked and roughly the same number blew up in my face, a rough framework fell out of it. 10 parts. Each one below has what held up and where it broke, because the where-it-broke half is the part I would actually want to read. I am posting it to get holes poked in it, so if you are building the same thing, tell me where I am wrong. 1. Put the whole company where the AI can read it (context as code) Stop wiring the AI into ten SaaS tabs. It is bad at clicking buttons and good at reading and writing files, so move the company to where it already works well, which is plain files in one repo. Every department is a folder. What held up. The AI went from useless across ten browser tabs to genuinely running things the day it could read and write the whole business as text. Where it broke. The folder gets fat and recall rots (there is a name for it now, context rot). You load context on demand. You do not dump the whole company into the window and pray. 2. A routing brain: one root file, departments as folders with playbooks Each folder holds a plain-English playbook (a CLAUDE.md) with who you sell to, your voice, the rules, the tools it may touch. A root file routes the work: TASK: "find leads and email them" | root CLAUDE.md (the router) | opens the playbooks that own the task v sales/CLAUDE.md + crm/CLAUDE.md (plain-English rules) | agent becomes that department head | does the work | writes the result back into the repo | next task starts with more context, not zero What held up. One generalist agent plus good playbooks beats a fleet of brittle specialised bots for most work, and cross-department tasks route themselves. Where it broke. A single generalist still drowns on genuinely complex parallel multi-step work. That is the only place I reach for subagents, because a multi-agent run costs roughly 15x the tokens, so it had better be worth it. 3. Own the tools that touch your core workflow, and treat every platform as hostile I rebuilt the internal SaaS I was paying for as small apps, each reading one database and one brand kit. A LinkedIn client that drives a real browser session. Its own CLI for Instagram. Google Workspace from the terminal, so an agent can book a meeting or send an email inside a workflow. The platform-facing ones taught me the most, the hard way. Early on an agent fired actions on a social platform in fast batches and the account got suspended. Fully deserved. So the clients now have hard daily caps in code (20 connects, 40 DMs, 80 profile views), run human-paced, and verify every send by counting the message elements before and after, because the compose flow silently changed twice and cheerfully reported success while nothing actually sent. What held up. Own the workflow tools (a session each, zero integration tax), rent the plumbing (database, email, payments, hosting, lead data). Caps in code, not in the prompt. And never believe a platform's own "success", check the DOM changed before you claim you did anything. Where it broke. Trusting the platform's word and moving fast. Both get you blocked or lied to. 4. Give it senses: a nightly Scout, intelligence digesters, inbound monitors, signal farming This is the part people skip, and it is most of the magic. The company perceives the world through a few standing flows: inboxes ----\ CRM --------\ rankings ----> SCOUT (nightly) --> one brief: what moved, what needs you competitors-/ feeds ------/ HN / Instagram / X / a FB community --> digesters --> scored signal + ideas LinkedIn + FB inbox --> hourly monitors --> new reply? --> queue + phone ping buyer-relevant posts --> signal farming (read + like only, 3x/day) --> lead pool all of it --> STRATEGIST --> the day's few highest-leverage moves
Reported result
The source reports no measured business outcomes or metrics. It describes a mixed experience where some operations worked while others failed, leading to the development of a 10-part framework. Specific failures included account suspensions due to rapid automated actions and silent send failures due to platform UI changes. The author states the goal was to stop doing admin, but does not quantify time saved or revenue generated.
Human role
I review on desktop or phone.
Limitations
Prerequisites include technical proficiency in Git, file management, and custom tool development. Constraints: Multi-agent runs cost ~15x tokens; single agents struggle with complex parallel tasks. Risks: Platform bans for automation; 'context rot' if files are too large. Integration uncertainty: Platform APIs/UIs change silently, requiring DOM verification. Human approval is required for all outbound actions. Source reliability is secondary (Reddit post).
Try it
I want to set up a one-person business automation system using AI agents in a single Git repo. Context: [replaceable inputs: business type, target audience, brand voice]. Source files: [replaceable inputs: existing CRM data, email templates, social media guidelines]. Target users: [replaceable inputs: customer segments]. Output location: [replaceable inputs: local directory path]. Steps: 1. Create a root CLAUDE.md file that acts as a router, defining how to distribute tasks to department folders (sales, marketing, etc.). 2. Create department folders with their own CLAUDE.md playbooks specifying rules, tools, and voice. 3. Implement a 'Scout' script that reads inboxes and feeds to generate a daily brief. 4. Build custom tools for LinkedIn/Instagram/Email with hard-coded daily caps (e.g., 20 connects, 40 DMs) and DOM verification for sends. 5. Run a dry run: Process one sample lead. Show me the drafted email and the verification logs before sending. 6. Wait for my explicit confirmation before executing any real sends or bookings. Quality check: Ensure context is loaded on demand, not dumped entirely. Verify that no platform limits are exceeded. Handle errors by pausing and asking for clarification if inputs are missing.
Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.