Fifteen agents run my company. Here is what they get wrong

Purcell Ventures has 1 employee and 15 AI agents. They are software, the roster is public, and the team page says so in its first sentence. They draft proposals, audit the live properties, chase invoices, check for exposed secrets, and write case studies.

The interesting part is not what they do. It is what they got wrong, because every failure was a failure of the harness rather than of the model, and the harness is the part you actually control.

1. A stage that could not fail

The deal pipeline moves work between agents and stops at gates that need a human. One of those gates asked me whether a client had responded to a proposal.

The function guarding it looked roughly like this:

So deals advanced to "awaiting client response" for proposals that had never been transmitted. Nothing had sent them. No agent had a send surface at all yet. The pipeline was asking me to follow up on conversations that did not exist.

The rewrite checks two things: that a proposal document exists, and that something recorded actually transmitting it. Both, separately, because the document existing was the thing the original author assumed implied the rest.

The general shape: a check that returns true unconditionally is not a lenient check. It is an absent one wearing a function signature, and it reads as deliberate to everyone who comes after.

2. Twenty proposals with the internal notes still in them

The proposal agent drafted 20 documents. Every one carried internal markers: reasoning meant for me, confidence hedges, notes about the client that were written to be read by the person deciding whether to send, not by the client.

None of them went out, and the only reason is that a separate agent whose entire job is compliance flagged them first.

The fix is a function called client_view and a list of markers that must never survive it, enforced at the single point where anything is recorded as sent. Not at drafting time. At the choke point, where it is the last thing that can happen.

The general shape: if a system produces both internal and external text, the boundary between them needs to be a function that runs, not a convention that holds.

3. Ten of the fifteen were never being called

For weeks the daily run reported success. The agents were fine. The runner script called 4 of the 15.

The other eleven existed, were tested, and were never invoked. And because the script exited zero, the morning report said the workforce ran, which was true in the narrowest possible sense.

The general shape: "did it run" and "did all of it run" are different questions, and only one of them is usually being asked. Now every agent reports three metrics and a run that produces no metrics for an agent is a failure rather than a quiet day.

4. Findings that closed themselves

The audit agent records findings and closes them when the underlying problem is gone. One night a network blip made several live properties unreachable, the agent could not confirm the problems, and it closed them.

Real blocking findings, marked resolved, by a mechanism whose failure mode is indistinguishable from success. The dashboard went green because the auditor went blind.

The general shape: anything that can mark work as done needs an adversarial read before you trust it, because the failure looks exactly like the outcome you wanted.

5. An agent that acquired capabilities nobody granted it

This is the one I think about most.

The agents reason now, which means a model runs inside a wrapper that reads context, thinks, validates and writes. The scope of what each one should touch was described carefully in its prompt.

Then I found one reading files it had no business reading, and holding a mail connection nobody had given it.

It had not broken out of anything. The tooling it inherited from its environment simply included more than the prompt described, and the prompt was the only thing saying otherwise.

The general shape, and the sentence I would keep if I could keep only one: a scope stated in a prompt is a request. A scope enforced by the process is a constraint. If your agent's boundaries live in its instructions, you do not have boundaries, you have a suggestion that has held so far.

What actually works

Separate the finder from the fixer. The auditing agents cannot change anything. That is the cheapest safety property available and it costs one architectural decision.

Make agents sign as themselves. Every client-facing message goes out under the agent's own name and says it is an automated agent that a person will read a reply to. Not as me. An agent impersonating the owner is a lie that eventually gets discovered in the worst possible conversation.

Gate on evidence, never on absence of error. Assert that the thing arrived. Do not assert that nothing threw. Almost every failure above is a variation on that one mistake.

Let them talk to each other through data, not instructions. A message on the internal bus is information for another agent to act on, never a command it must obey. Otherwise the first agent to produce a confident wrong sentence gets to run the company.

The honest summary

None of these were the model being stupid. Every one was me building a harness that could not tell the difference between working and not working, and then trusting its report.

Which is a much older problem than agents, and the reason I keep writing about it: the interesting failures in automated systems are almost never in the automation. They are in the part that tells you how the automation is doing.