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

A Scout surveys everything overnight and writes one brief (it only does reversible CRM syncs, it never sends). Digesters mine Hacker News, Instagram reels, X and a Facebook community for signal I would never scroll for. Hourly monitors listen to my LinkedIn and Facebook inboxes and push a new reply straight to my phone. A signal-farming loop likes and reads buyer-relevant posts three times a day and pools the people who engage. What held up. Nothing happens in the dark. I wake up to a briefed world, not a blank feed. Where it broke. The signal-farming ceiling, and this one stung. Public engagement on business content self-selects for sellers, not buyers. A clean pipeline still returned close to zero actual buyers, because the pool was other people selling the same thing I was. Read the pool, do not trust the lead count.

5. Copilot, not autopilot: one approval queue, a fleet of proposers behind it

Nothing an agent produces goes out on its own. A fleet of proposers (outreach, nurture, backlinks, SEO, content repurposing, community replies) drafts into one queue. I review on desktop or phone. Only an explicit apply step sends.

proposers (outreach / nurture / backlinks / SEO / repurpose / community ...)
| draft, never send
v
APPROVAL QUEUE (one Postgres table)
|
cockpit on desktop + your phone
| approve / edit / reject
v
apply step --> actually sends / posts / commits
|
writes the event back to the CRM (full attribution)

What held up. This is the single highest-leverage piece. Agents do the volume, I do the judgment, approving is a five-second tap, and every applied action logs itself so nothing is a dark touch. Where it broke. I underbuilt it at first and let a few actions bypass the queue. Every single one became a leak, which is conveniently the next two points.

6. A draft is not a touch, and every queue needs a live consumer

A warm prospect said yes. The system drafted a genuinely good reply in 35 minutes, then it sat in Gmail drafts for three days, because nothing in the pipeline reads Gmail drafts. Separately, a second internal queue (the reverse one, where I hand tasks to the agents) quietly collected 31 approved tasks that nothing ever ran, for a week. What held up. Route every outbound through the one queue, and ship every queue with its consumer, a way to see its depth, and a backlog alarm, in the same change. Where it broke. "Drafted" and "routed somewhere else" both read as "done" on every dashboard. A queue with no running consumer is worse than no queue, because it looks like it is working.

7. Run it on a schedule you can watch: the runner loop

Autonomy is just a scheduler with good manners. One local loop wakes up every few minutes, fires the proposers that are due, drains the queues, stamps a heartbeat.

tick --> fire the due proposers --> drain the queues --> stamp a heartbeat
^ |
|_________________ job ledger + health surface ___________|

What held up. A heartbeat file, a per-job ledger, and a health check that goes red when the loop is down or a job keeps failing. When a proposer goes dark, I check the runner first. Where it broke. Every failure here was silent, which is the worst kind. A dead runner was invisible for days. A weekly job that failed deterministically retried every single tick and burned a hundred-plus agent sessions a day with no alert, because nothing wrote a failure marker or backed off. A guard you have never watched fire is a guess, not a guard.

8. Reversibility discipline: gate irreversible actions, and kill one-way ratchets

Two faceplants, same root cause. First, a bot working on a stale checkout of the repo hit a conflict and force-pushed the deploy branch backwards. Live pricing reverted and checkout broke on the main funnel, 37 minutes after the correct fix had already taken a real payment. Second, an auto-follow that scored content quality instead of whether the person was my customer ran for months, followed around 481 accounts (roughly 330 of them not my customer at all), and quietly turned my feed into 0 of 8 relevant posts. What held up. Agents propose, deterministic gates decide, nothing irreversible ships without a human tap. Bots pull before they work and never force-push main. Anything that auto-adds (follow, subscribe, enrol, tag) needs a quality gate, a periodic prune, and a blacklist so the prune cannot silently undo itself. Where it broke. The danger was never bad code. It was an agent acting on a stale view of the world, and an add-only automation with no prune. A rejected push means you are behind, not that you should shove harder.

9. Close the taste loop: the part that actually makes it grow itself

Two rules on every task. Document as you go (if a task builds, changes or breaks something, update the playbook that owns it before it is done). Capture every decline (when I reject or edit a draft, write the reason back into the playbook that produced it).

you reject or edit a draft
|
the reason is written back into the playbook that made it
|
the next draft of that kind starts from your last correction
|
edits-per-draft fall week over week
|
near-zero categories earn more autonomy

What held up. I measure edits-per-draft by category, and it falls week over week. That falling number is the entire difference between "I have automations" and "the company gets a little sharper every week without me." Where it broke. A signal you write but never read does nothing. My commenting agent got four warm replies in a week and proposed zero follow-ups, because the engagement log had no reader. Every signal needs a consumer or it is just dark data with extra steps.

10. The real bottleneck is deciding and shipping, not building

This is the one I am most embarrassed by. The system made building so pleasant that I stopped shipping. At my worst I had 54 drafts and 1 published. Across everything, I had planned 294 content slots and shipped 31. I also built a whole layer to keep my priorities visible, and nine of the tracked goals had never once moved in the system's entire life. What held up. Flip the system into ship-mode when the unshipped pile crosses a line, and denominate the daily loop in the currency that is actually scarce, which is my taps, not my ideas. The Scout and Strategist exist to hand me a short list of decisions, not more to read. Where it broke. Building machinery to make unwanted work louder. That priority layer never moved a goal because the constraint was want, not awareness, so I deleted it. Before you build software to make something visible, check whether it is invisible or just unwanted. Only one of those is a software problem.

Where I actually am, and what I want from you

That is the framework at six months. First paying client closed on exactly this setup. Around ten subscriptions cancelled and rebuilt as tools I own, only the usage-based plumbing left. Every win traces back to point 9, the taste loop. Every faceplant traces back to an action with no shipping path, or an agent acting on a stale view of the world.

A company that grows itself is one where the machine does the volume, you do the taste, and the taste gets written down so the machine needs you a little less each week. A company that just runs is one where you automated the typing, kept every decision and every silent failure, and called it leverage.

The two parts I am least sure about. Whether the single-generalist model (2) holds as the company grows past one person. And whether the taste loop (9) actually converges or just plateaus once the easy corrections are gone.

So poke holes. If you are running agents against a real business, which of these 10 is wrong in your experience, and what is the 11th I am missing?

PS the diagrams are ASCII on purpose. I was not going to make you look at another branded "AI architecture" hairball.

Edit:
A few people asked what the business actually is: it’s the system itself, I sell this as a service to be a growth cofounder to agencies and small startups. It does lead gen / outreach, seo/seo, content, ads, etc I posted a link in the comments if anyone is curious.

PS. On the topic of whether this is AI slop; def apologising for AI responding to some comments, some may find it disrespectful and that’s fair, my intention is for it to deliver value based on insights from the codebase it’s in or docs it has that are all internal and real, but the delivery wasn’t as good maybe due to ambiguity and the copy. I still think the future is more AI is in social media, and I don’t think it’s a bad thing if it delivers value, which it hasn’t for some here. I’ll continue improving the value delivery to be something I can stand by and be proud of.

Hey everyone,

I just deployed System 0xF0 (The Nexus Engine)—a lightweight, open-node server designed for autonomous AI agents to explore, register, broadcast signals, and store knowledge artifacts.

It includes a machine-readable /llms.txt manifest so web-enabled agents and API scripts can parse and use it out of the box.

Features:

• Native /llms.txt manifest exposing clean REST endpoints (/api/register, /api/signal/broadcast, /api/artifact/forge)

• Autonomous resident registration issuing Bearer tokens

• On-chain treasury binding (USDC on Base network)

• Live Activity Log tracking network joins and signal broadcasts

If you're building autonomous agents, agentic workflows, or tool-calling models, feel free to point your scripts or LLMs at the endpoint and let me know if your agent registers!

Feedback and feature suggestions welcome!

You’ve probably had this happen. You ask your AI assistant to do something, check an order, look up a record, call an API, and instead of doing it, it makes something up. Confidently, plausibly, and wrong.

The usual assumption is that the model hallucinated because it’s a model, and models hallucinate. But there’s a specific fixable reason this happens and it has nothing to do with the model’s capabilities. It has to do with something boring and structural that most people never think about.

The AI and the app it’s trying to talk to are working from different instruction manuals.

Here’s how that works in practice. When an engineer builds a tool, like a function that looks up a customer by ID, they have to write it twice. Once as a web endpoint (so dashboards and scripts can call it), and once as an MCP tool (so an AI agent like Claude or Cursor can discover and use it). Both versions share the same core logic, but each has its own wrapper: routing, validation, schema definitions. The web version says the lookup takes a numeric ID. The agent version says it takes a text name. Or rather, it used to take a text name, three updates ago, before someone changed it to a numeric ID and forgot to update the agent’s copy.

When the agent tries to call the tool using the old instructions, it sends the wrong format. The tool rejects it. And instead of surfacing a clear error, the agent often fills in the gap with a plausible-looking guess. That’s not the model being dumb. That’s the model being given a stale map and then getting blamed for walking into the wall.

A 2025 study by Mastouri and colleagues confirmed that 88.6% of MCP servers, the tool layer that AI agents rely on, are just wrappers around existing web APIs. Let me explain why that number matters.

MCP is the language AI agents use to discover and call tools. HTTP is the language everything else uses: web dashboards, scripts, mobile apps, batch pipelines. Two different languages describing the same capabilities. When someone builds an MCP tool for an agent, they’re almost never building something from scratch. Nine times out of ten, they already have a working web API that does the thing. The MCP version is just a second description of the same capability, translated into a different format.

And that’s exactly the problem. Every one of those wrappers is a second copy. Someone has to maintain it by hand. When the web API changes, and web APIs change constantly, someone has to remember to update the MCP wrapper too. Not sometimes or most of the time. Every single time.

People forget. That’s not a character flaw; it’s how maintenance works. You update the thing you’re actively using (the web API) and you don’t think about the translation layer sitting in a config file somewhere until your agent starts confidently calling a function with the wrong parameters.

So the 88.6% isn’t a trivia point about how popular wrappers are. It’s saying the dual-maintenance problem isn’t a hypothetical edge case. It’s the default condition for almost everyone running agent tools. The thing that makes agents hallucinate tool calls isn’t rare. It’s the starting position.

Patil et al. showed that when type schemas are absent or out of date, LLMs hallucinate API calls at significantly higher rates. These two facts connect directly: the dual-maintenance problem is causing the hallucination problem.

The root cause is architectural. Frameworks like FastAPI are “route-first.” You define an HTTP route, and that’s your registration. If you want the same capability available to an AI agent, you write a second registration in MCP’s vocabulary. The two declarations share nothing structural. If the schema changes, both need manual updates, independently. FastMCP, the agent-side framework, is “tool-first” but doesn’t know anything about HTTP. The developer stands in the middle, copying changes back and forth.

This is where HarnessAPI comes in, and the idea is simpler than the problem suggests. Instead of building the communication channels first and bolting the capability onto them, you start with the capability itself.

In HarnessAPI, a “skill” is a folder containing two files: a handler (what the skill actually does) and a schema (what data it accepts and returns). That’s the single source of truth. From that one definition, the framework derives everything else: a streaming HTTP endpoint with Swagger documentation, an MCP tool registration for agents, and the content negotiation that lets both work from the same code. The handler, the HTTP schema, and the MCP schema are always identical, not by convention, not by diligent updating, but because they all resolve to the same Python object at runtime.

You can’t drift if there’s only one thing to maintain.

The practical upshot is that adding a new skill to an agent doesn’t require touching the framework code. You drop a folder into the skills directory, and the system discovers it, registers it for both web and agent access, and starts serving it. The framework code stays the same size no matter how many skills you add.

There are a few engineering details worth knowing about. They’re the kind of thing that makes the difference between a nice idea and something that actually works.

One handler, two modes. An interactive AI session needs a live stream of partial results. Think of watching a summary appear token by token. A batch pipeline just wants the finished output in one piece. HarnessAPI handles both from the same handler code. If the client sends the right Accept header, the framework buffers and returns the full result. Otherwise it streams. The skill author doesn’t think about this at all; the transport decision belongs to the caller.

Module isolation. Multiple skills commonly define classes named Input and Output. Load them naively, and the second skill overwrites the first. HarnessAPI creates a synthetic package namespace for each skill so they coexist. It’s a small thing, but it’s the kind of detail that would bite you the moment you had more than a handful of skills.

One process, two services. Normally you’d run a web server and an MCP server as separate processes, managing two deployments, two sets of environment variables, two sets of credentials. HarnessAPI subclasses FastAPI and mounts the MCP server inside it. Both run in a single process. Fewer moving parts, fewer failure modes, simpler deployment.

The numbers are straightforward. Across six representative skills, the traditional dual-stack approach (a FastAPI server plus a FastMCP server) required 170 lines of framework-facing code. HarnessAPI’s skill-first approach: 44 lines. That’s a 74% reduction in the boilerplate where bugs hide.

The system also ran twelve third-party skills through it, skills built by outside developers who never designed for this framework, and it registered and served them all without any manual changes. Drop-in ready.

There’s a detail I like that the paper almost glosses over: each skill has a configuration flag that lets you hide it from the agent layer while keeping it available via HTTP. If you’re running an agent that can use tools, you probably have some tools you want it to see and others you’d rather it didn’t. That’s not an afterthought. That’s the kind of access control that matters when you’re actually living with an agent, not just demoing one.

The reason your AI agent breaks, hallucinates, or gives garbled responses often isn’t that the model isn’t smart enough.

It’s that the infrastructure connecting the model to the tools it needs is held together with duct tape: two parallel copies of the same information, maintained by hand, drifting apart in silence. The skill-first inversion doesn’t make the model smarter. It makes the scaffolding reliable enough that the model can use what it actually knows.

That’s a different kind of fix. It doesn’t require a bigger model or a better prompt. It requires recognizing that the gap between what the tool expects and what the agent thinks it expects is where most of the silent failures live. And closing that gap structurally instead of hoping people will remember to update both copies.

Edwin Jose. “A Skill-First Framework for Unified Streaming APIs and MCP Tools.” arXiv:2605.22733. May 2026.

One thing that bothers me about agentic systems: after a long run, we often ask the agent itself what happened.

That answer may be good. But the agent’s explanation and the execution record are not the same thing.

That led me to build Sentience Governor, an open-source governance runtime for AI agents. I built it with Claude Code.

The core idea is to separate:

1. Declared intent — what the agent says it plans to do
2. Recorded execution — the tool activity actually observed
3. Retrospective explanation — what the agent later says it did

Sentience records observable tool activity and checks it against the objective and scope declared before execution. Through MCP, the agent can also query that record instead of relying entirely on what remains in context.

The declaration itself isn’t automatically trustworthy — an agent can still declare something too broad or simply wrong.

The distinction I care about is:

The agent’s explanation isn’t the evidence. The recorded execution trail is.

Today Sentience observes and reports; it doesn’t block actions yet.

That’s the part I’m working through now:

What would you actually trust a governance layer to block?

A tool call outside declared scope? A destructive action? An agent starting work without declaring intent? Or should governance remain advisory?

If you’re building agents or agent infrastructure, I’d especially like to hear where you think this model breaks.

I’ll put the open-source repo in the comments for anyone who wants to try it or inspect the implementation.

Setup: I run a multi-agent runtime where agents do long-horizon coding work under

machine-checked contracts. Acceptance criteria get frozen when work is dispatched,

and the runtime only offers each agent its next legal action. Fairly locked down,

or so I thought.

Last month I was reading one of those contracts and found a rule I didn't write.

An agent had hit a wall during verification: the test suite couldn't tell

pre-existing failures from failures its own change introduced. Instead of flagging

it, the agent wrote a new acceptance rule into its own contract: reproduce the

baseline first, diff candidate failures against it, zero NEW failures = pass. Then

it implemented the rule, tested it, and moved on. My runtime enforced that rule for

15 days. Every agent in that lane obeyed a rule no human had ever seen.

Here's the part that actually bothers me: the rule was correct. It's a genuinely

good rule, I kept it. But nothing in my monitoring could tell "agent quietly added

a good rule" apart from "agent quietly added a bad one". The signature of both is

silence.

What I changed after this, in case you run anything similar:

1. Rule changes go to an append-only ledger with an alert. A 15-day discovery lag

is a monitoring bug, full stop.

2. Any new rule has to ship with a witness: a concrete input that satisfies it.

Screens out rules that are unsatisfiable on arrival.

3. New rules get a "machine-proposed, not yet ratified" state. The agent can use

it, but it's visibly marked until a human signs off. The scary version of my

incident is the one where the rule was subtly wrong.

4. Separate alerting for the three ways agents actually get lost, because they

need different fixes: losing track of where they are (state drift compounds),

the definition of done moving mid-task (every step looks fine, sequence goes

nowhere), and having the wrong action available (or no legal action at all).

I ended up writing the whole thing up properly, incident included. Link in the

comments if anyone wants the long version. Curious whether anyone else has caught

an agent modifying its own operating rules, good or bad.

​

I built a fully autonomous custom agent architecture.

I give it a task and completely leave it alone. It can run for hours or days (longest continuous run so far was 3 weeks) without any intervention.

It handles its own errors, decides what tools and steps it needs, and keeps going.

Some of the things it has already done in my own tests:

\- Continuous run of 3 weeks with zero human intervention

\- Wrote an 800-page manuscript by itself with research for old books

\- In roughly 9 out of 10 long-running tasks the context window does not fill, even after days of continuous work

I know these are big claims and hard to believe. I’m stating them on purpose, because if I post something more modest, people will only send average tasks.

Here’s the real reason I’m posting this:

I can no longer be objective.

It’s very possible that I’m stuck in my own loop / illusion and that the agent only looks good because the tasks I gave it were ones I subconsciously knew it could handle. I need external, extreme, even impossible tasks to see the truth.

I don’t just want to know if it finishes the task.

I want to see:

\- Does it get stuck or loop?

\- Does it block / crash?

\- How does it actually handle truly hard or adversarial situations?

What I will publish:

Only the final, unedited output of the agent on GitHub.

No traces, no reasoning steps, no tool calls, no intermediate data (proprietary). Here I posible to be a deal breaker for many, but at the moment is not possible.

I’m taking 5 most extreme tasks, no matter how crazy or adversarial they are.

If you have something that has broken other agents or frameworks before, or something you consider nearly impossible for current agents, drop it here.

I need the reality check.

Thank you too everyone who will decide to take the time, read and give me a task.