“Make the agent more reliable.” “Prepare the platform for scale.” Each request points toward a real concern. Neither is precise enough to build against.
The usual mistake is to translate the request directly into a technical project. Reliability becomes a new evaluation service. Scale becomes a queue. The team can spend weeks delivering the proposed mechanism while the original concern remains unresolved.
I treat the request as evidence that someone sees a gap. My first job is to define the gap in a form that can force a decision.
Name the person and the finish
I ask who is waiting for a different result and what they should be able to observe when the work succeeds.
Suppose the request is to make a voice agent more reliable. “The model answers accurately” describes one component. The caller may still repeat information, wait through a stalled tool call, or hear a confident confirmation for work that never completed.
A stronger finish could be: for callers attempting a supported task, the system either confirms the completed external effect or transfers the call with the relevant state intact. The statement identifies the user, the task population, the accepted terminal states, and the evidence of completion.
Once the finish is visible, the team can disagree usefully. Product can challenge the supported task set. Operations can define an acceptable transfer. Engineering can test whether external effects are observable. The request has become a shared object instead of five private interpretations.
Find the earliest failed assumption
A system reaches an outcome through a chain of claims. The caller’s intent is recognized. The requested action is authorized. A tool receives valid input. The external system records the change. The agent observes that effect. The caller receives an accurate account of the result.
The useful question is: where does failure first become inevitable?
If intent recognition is weak, recovery logic after the tool call will not help. If authorization is unclear, better model reasoning increases the chance of an unsafe action. If the external effect cannot be observed, a polished confirmation remains a guess.
I write the leading explanations and choose the cheapest test that separates them. The test may be a trace review, a manually labeled cohort, a fault injection, or a temporary measurement. Its purpose is discrimination. A test that confirms every plausible story does not reduce the decision.
Separate the operating bar from the aspiration
Teams often mix the result required for the next decision with the result desired eventually. That makes every proposal look incomplete and every project difficult to finish.
I record two thresholds:
- The operating bar states what must be true before the system can serve the intended use safely.
- The improvement target states the next result worth pursuing after the bar is met.
The distinction protects both speed and quality. The team can ship when the required conditions are satisfied. It can continue improving without pretending the current release has failed.
Write the decision before the project plan
A plan lists work. A decision record explains why that work should change the outcome.
| Field | Question |
|---|---|
| Outcome | What observable result must change? |
| Population | For which users, tasks, and operating conditions? |
| Current evidence | What shows the gap, and how trustworthy is it? |
| Constraint | Which mechanism currently prevents the result? |
| Decision | What will we do, and which alternatives did we reject? |
| Owner | Who can change the choice and who operates the result? |
| Review trigger | Which evidence would make us revisit the decision? |
The record can be one page. Length adds little if the constraint remains vague. A useful record lets an engineer joining later reconstruct why the chosen work was expected to matter.
Keep uncertainty attached to the decision
The decision becomes usable when its remaining uncertainty has bounds.
I label assumptions that remain open and connect each one to a consequence. If traffic grows beyond a stated range, the storage choice changes. If transfer quality falls below the operating bar, the supported task set narrows. If the external system cannot provide idempotency, retry behavior changes.
This is more useful than a general risk list. Each uncertainty has an observation, an owner, and an action. The team knows what to watch and what the signal will change.
Force the next decision
The output of early architecture work should move the system closer to an observable result. Sometimes that output is a design. It may be a measurement, a product ruling, a reduced scope, or evidence that the current system is adequate.
I consider the framing complete when the team can answer five questions:
- Whose result are we changing?
- How will we observe the finish?
- Which assumption currently controls the decision?
- What is the smallest useful test?
- Who owns the decision after the meeting?
The useful deliverable is a finish precise enough to reject irrelevant work. Once the finish, constraint, test, and owner are clear, the engineering can begin.