The Agent Did the Work. I Owned the Outcome.

TL;DR

• A cheaper, faster model looked promising for OpenChair's Style Match feature. Incorrect assumptions and weak eval results stopped it from reaching customers.
• Specialist agents covered product framing, UX, engineering, review and release, but another agent opinion was not the same as independent judgement.
• Agent teams spread execution across more workers while concentrating responsibility on the human who approves the release and faces the customer.

---

The replacement model was cheaper and faster. I still would not put it in front of a customer.

I was evaluating a new model for Style Match, an OpenChair feature that recommends services from a client's photos and preferences. The candidate had already cleared the easy test. It ran. It produced structured answers. The cost and latency looked attractive.

Then we ran it against the demo data and eval cases we had built for the feature. The results exposed incorrect assumptions and scores that were not good enough. The candidate did not reach customers.

There was no dramatic failure. Nothing crashed. The recommendations could look plausible if I inspected a few convenient examples. That was the danger. I could have accepted the cost improvement, told myself we would refine quality later and shipped a model that had not earned the decision.

By then, I had a roster of specialist agents helping me build OpenChair. They could investigate the feature, implement the model change, run the evaluation, review the result and prepare a release. The workflow looked like a team doing its job.

Only one person had to decide whether the evidence was enough.

I Had Built Something That Looked Like a Team

Most consequential OpenChair work began with a product agent. It would inspect the existing behaviour, research competitors and the market, review customer transcripts and frame the problem.

A UX agent would challenge the workflow. It looked for places where the proposed interaction did not match how an operator worked, then brought in patterns and design-system constraints. Once I accepted the direction, a full-stack engineering agent traced the architecture, wrote the technical plan and implemented it. Separate review and release modes could inspect the result and prepare it for production.

The roles were bounded. Strategy was read-only. Implementers could change the repository inside an accepted plan. Mechanical work stayed separate from decisions about product, security, billing or architecture. Review was kept away from the writer where the workflow allowed it.

This was far more useful than asking one general-purpose assistant to build whatever I described. Product framing stopped engineering from solving the nearest technical problem. UX caught coherent flows that were awkward for a salon. Engineering exposed product ideas that would leave brittle data or migration behaviour behind them.

It felt like directing a compact product organisation. That feeling could become misleading.

The agents did not carry a decision from one week into the next. They did not lose sleep over a weak release or remember that they had argued confidently for an approach that later failed. They had roles in the workflow without having anything at stake in the outcome.

A Second Opinion Was Not Necessarily Independent

I learnt quickly that asking again did not necessarily give me an independent view.

I could challenge an agent's recommendation and receive some version of: "You're right to push back." Sometimes the revised answer was better. Sometimes it merely followed my new framing.

That is a difficult failure mode because it feels like review. The first answer creates a position. The challenge appears to test it. The second answer arrives with a reasoned correction. Two passes through the system can leave me more confident without producing better evidence.

Specialist modes reduce part of this risk because they start with different briefs. Product looks for market and customer coherence. UX follows the operator through the interaction. Engineering cares about what the system will do under load, during migration and at the edge cases.

Those perspectives are still produced from overlapping context by systems designed to be helpful. None of them bears a cost for agreeing with the person asking the question.

I had to keep hold of the original problem, the customer evidence and the standard I intended to apply before seeing the answer. Otherwise I could continue prompting until the system endorsed the decision I already wanted to make.

Style Match did not stop because an agent developed conviction. It stopped because the eval made a convenient answer harder to accept.

A Salon Booking Broke the Internal Story

Another OpenChair decision began with a customer showing us a booking that was wrong in a particularly salon-specific way.

The system had turned a multi-service booking into back-to-back work where a processing period should have existed. On paper, the durations added up. On the salon floor, the sequence was wrong.

Hair appointments are not simple blocks of time. A colour service can contain active work, a processing period and another active step. Some work can fit inside the processing window when the operator accepts it and the constraints allow it. Other time must remain blocked. Services cannot be silently rearranged because an algorithm found a tighter calendar.

The original implementation flattened that operating reality. It stored duration while losing the meaning of the time inside it.

Once the customer evidence was clear, the agent workflow was useful. Product could restate the problem. UX could trace what the operator expected to see. Engineering reconstructed the timing model as ordered active, processing and blocked phases, then added regression coverage.

The agents were better at fixing the system after the world had been described correctly. They could not decide, on their own, that our existing model of the world deserved to be discarded.

That authority came from the customer evidence and my decision to let it invalidate work we had already done. A technically consistent implementation had to move because it was consistently wrong.

Green Tests Were Still Only Evidence

The same problem appeared closer to production.

OpenChair's release workflow can freeze an exact candidate, validate database migrations, stage a deployment, run automated checks and preserve enough information to diagnose or recover from a failure. It removes a long list of routine mistakes I could make while releasing software alone.

One corrective release accumulated passing evidence across the automated suites and staged checks. Physical phone verification still found broken behaviour. In a separate production check, clearing a browser and reconnecting could fail because a redundant local sign-out step failed first.

The automated evidence was real. It showed that the code behaved correctly under the conditions we had specified. A person holding the device had supplied a condition we missed.

That gap is why the language around autonomous agents becomes too loose for me. The release agent can perform the procedure. It can stop when a gate fails, preserve the candidate and help diagnose the fault. It cannot decide that passing evidence is sufficient when the actual workflow is broken.

I make that decision because I carry what comes after it. A bad release costs time. More importantly, it puts customer trust at risk. The agent can repair the code, but it has no relationship to restore.

The Pattern Was Bigger Than My Repository

Several recent conversations on Lenny's Podcast made the same ownership problem visible in different functions.

At Whatnot, Tom Verrilli described why product managers should be assigned to problems, not added automatically whenever an engineering team reaches a particular size. Engineers and designers need enough context and responsibility to exercise product judgement themselves. A PM can help with a difficult decision without becoming the permanent owner of every decision around the team.

Cursor's Adam Ward drew a similar line in his discussion of talent density. Recruiters run the process and help a hiring manager build confidence. They do not make the hiring decision or live with the performance of the person who joins.

Elizabeth Stone described the AI version at Netflix. Roles are becoming more fluid and agents can perform more of the work, while humans remain responsible for what they create.

The common mistake is giving accountability to the function coordinating the work when another person makes the decision and bears the outcome.

Product management can coordinate. Recruiting can coordinate. An agent can investigate, implement or review. Coordination does not transfer ownership.

More Execution Created a Narrower Point of Responsibility

Building with agents gave me more capacity to act. It also sent more decisions towards a single review boundary.

I call this accountability compression. Execution fans out across specialist agents while product, technical and customer responsibility collapses back onto the human owner. The implementation queue gets shorter. The judgement queue fills faster.

That pressure changed how I worked.

I began recording the decision standard before seeing an eval result. An attractive output should not get to rewrite the test it just failed.

Implementation and review received different briefs and permissions. That reduced shared blind spots without pretending the reviewer had authority.

Customer evidence could invalidate the model, even after implementation work had accumulated. Agent speed makes rebuilding cheaper. It also makes defending sunk work easier because so much can appear overnight.

Production authority stayed explicit. Release automation made an approved decision safer. It did not turn technical completion into approval.

The formal operating model sits in Every Agent Needs an Owner: name an outcome owner and a system owner, constrain permissions, define evals, budget human review and retain a way to stop the agent. Those controls matter for agents inside a product and for the agents used to build it.

OpenChair taught me why the human owner cannot be a ceremonial name in that document.

I could delegate most of the work that produced a decision. I still decided which evidence to believe, when to stop, what could reach production and whether I was prepared to ask a customer to trust the result.

The agents gave me more range. The responsibility did not spread with the work. It concentrated.