If writing agent instructions is programming, it follows that the best instructions aren’t written by one person in isolation.
They’re a team sport.
When I say “business” here, I often mean a PM — that’s how we do it. But it could just as easily be a founder, ops, customer support, or anyone close to the user and the outcomes. The key is: someone owns the intent and constraints, and engineering owns the control flow and guardrails.
Because building a useful agent requires two different kinds of thinking:
- product thinking: what outcome are we trying to achieve, for whom, and what does “good” look like?
- engineering thinking: how do we make that behaviour reliable in the messy real world?
When either one is missing, the agent fails in predictable ways.
What the PM/business brings: intent, outcomes, and constraints
A good PM (or someone thinking like one) is often better than an engineer at the parts that matter most:
- what is the user actually trying to do?
- what does success look like?
- what should the agent optimise for (speed, certainty, clarity, cost)?
- what constraints matter (tone, compliance, brand, risk)?
- what should the agent never do?
This is the intent layer.
It’s the difference between “generate a status update” and “reduce customer anxiety, be clear, don’t over-promise, don’t contradict what the customer sees elsewhere.”
If you skip this layer, you can end up with instructions that are technically precise but solve the wrong problem.
What engineering brings: control flow, safety, and failure handling
Engineers bring the reliability layer.
This is where you decide:
What engineering brings: control flow, safety, and failure handling
Engineers bring the reliability layer.
This is where you decide:
- what data the agent can access and what it can’t
- what to do when key fields are missing
- how to avoid hallucinating details
- how to handle edge cases and weird states
- how to stop safely when confidence is low
- how to keep outputs consistent and testable over time
This is the part that turns “goal + constraints” into something you can trust.
It’s also where you often prevent the most expensive failures: the confident-sounding wrong answer.
The collaboration loop that works in reality
Here’s a simple workflow that’s worked well for us:
- PM drafts the intent
- Goal, success criteria, constraints, tone, and what to avoid.
- Engineer turns it into an executable spec
- Steps, conditionals, failure handling, stop conditions, and output format.
- Run it against real examples
- Find where it breaks, especially around missing/ambiguous inputs.
- Add guardrails for the failures you actually see
- Don’t try to anticipate every hypothetical. Tighten it iteratively.
This is the same way we build software: start with a spec, test against reality, and refine based on observed failure modes.
Common failure modes when you don’t do it together
If it’s mostly product-led and not enough engineering control flow, you get:
- great tone, unreliable behaviour
- vague “be helpful” instructions
- hallucinations when data is missing
- inconsistent output formats
If it’s mostly engineering-led without enough product intent, you get:
- reliable behaviour that feels robotic or misses the point
- outputs that are technically correct but unhelpful for users
- agents that optimise for correctness at the expense of clarity or reassurance
The best agent instructions combine:
- PM/business intent (why / what good looks like)
- engineering control flow (how it behaves, especially when things go wrong)
That’s why it’s a team sport.