PBA at Work
From business decision to 1,300 behavior cards.
On the agentic health startup I’m building, one leader carried the business model, the product behavior and the handoff to coding agents. Here is how it ran, what failed first, and what I learned from the people I built it with.
Why behavior cards? Because agents should be coding, not reading.
The Process
From concept to business-based behaviors.
Every number below comes from the build. Claude drafted and red-teamed at volume; a person made every ruling, numbered and dated.
Behaviors, not features: every card says what the agent does, what it must never do, and how to check it.
What Failed First
The first spec set failed.
It was detailed and faithful to the design. It also carried every debate, draft and dead end, so the agents couldn’t find the signal. The fix wasn’t more documentation. It was decided, current, simple and consistent behaviors.
1
Noise hid the signal
Design history, open questions and superseded decisions sat next to current rules, and agents treated all of it as truth.
2
A 20-pass reconciliation
Claude found and resolved conflicts across the whole corpus, pass after pass, until every rule was current and consistent.
3
4 versions, 3 releases
The spec went through 4 versions across 3 releases before the behavior cards were ready to build from.
After the cleanup, agent output with QA came back really close to spec.
The Behavior Card
One behavior per card. Written for agents.
Each card is one rule an agent can build from and a tester can check. Long specs became cards, features and stories became behaviors, and “what to build” gained “what it must never do”.
Before
Long specs
One behavior per card
Features and stories
Behaviors
What to build
What it must never do
Design history mixed in
Current state only
Interpreted by engineers
Executed by agents, verified by tests
S
Statement
The behavior in one sentence.
D
Does
What the product does, step by step.
N
Never
What it must never do, in business, user and clinical terms.
✓
Why and Check
The decision it traces back to, and how to check the behavior.
What Changed
The critical path moved from building to deciding.
Once the specs were clean, the build stopped being the slow part.
Engineer time
About an hour per round of changes.
After the clean specs, the engineer spends 30–45 minutes writing the instruction and 15–20 minutes checking runs, reviewing and pushing. Agents run day and night.
Well under a quarter of an engineer’s time.
Agent output, with QA
Really close to spec.
After the reconciliation, what the agents built matched the behavior cards closely enough to review rather than rebuild.
Review, not rework.
Decisions
Every ruling numbered, dated and owned by a person.
Claude drafted and challenged; the product owner decided. Each ruling is recorded, so agents never re-decide something already settled.
No silent re-decisions.
Where the time went
Deciding became the work.
Agentic capacity is now budgeted like developer hours. The IP, and the time, sit in the decisions.
The spec is the asset.
What I Learned
Lessons from building it with others. You get them on day one.
I learned these working alongside the engineers and designers on the build. They are now part of how PBA runs.
Bring engineering in early
Design and build work best as one conversation.
Working with our engineer showed me how much faster the build goes when engineering shapes the design, not just receives it.
Build the core engine first
Make the engine its own testable piece.
Extracting the core engine before the surfaces makes it testable on its own and reusable for partners.
Test against the spec, not the code
Let the behavior cards define done.
Integration tests written from the specs, not from existing code, show whether the engines behave as designed.
Book a Discovery Consult
Free. No commitment.