In this article
Last updated September 18, 2026
3 min read
An AI agent can investigate a decision for thousands of tokens.
It can inspect code, compare patterns, read documentation, run checks, and argue for one option.
Sending all of that to a product owner or engineering lead does not keep them informed. It transfers the agent’s context
problem to a human.
A decision packet performs a different job: compression without hiding the choice.
What belongs in a decision packet
The decision
Write one sentence that can be answered.
Weak: “Review the invitation implementation.”
Useful: “Should organisation members with the manager role be allowed to invite new members, or only administrators?”
Why the workflow stopped
Explain why the system cannot safely proceed.
The specification may be silent. Two repository sources may conflict. The choice may change access, architecture, data,
cost, or a public contract.
Affected boundary
Name the user behaviour, module, interface, risk, and dependent artifacts.
This keeps a local-looking question from hiding a wider consequence.
Realistic options
Present viable choices, including maintaining the current behaviour when relevant.
Do not make the preferred option detailed and the alternatives vague.
Evidence
Include:
- current code and behaviour;
- relevant written rules;
- test and check results;
- usage or operational data if available;
- specialist findings;
- known precedent;
- source dates and limitations.
Recommendation
The agent or specialist can recommend an option and explain why.
Label it clearly. The recommendation is judgement, not proof.
Uncertainty
State what remains unknown and what evidence would reduce it.
Owner and deadline
Name the person or role authorised to decide and when the decision is needed.
Keep the packet writable by one owner
Structured workflows can suffer from conflicting writes. Several agents append opinions, change the selected option,
or rewrite the reason.
Use a clear writer rule:
- specialists submit findings;
- one decision-packet writer normalises the material;
- the named human records or confirms the decision;
- later changes create a new event rather than rewriting history.
This keeps the record coherent.
Connect the answer back to execution
The packet is not finished when the human clicks a button.
Apply the answer to:
- specification;
- acceptance criteria;
- plan and scope;
- risk lane;
- implementation instructions;
- tests and evidence plan;
- repository rules;
- decision memory;
- documentation.
Then resume from the paused workflow step.
The structured state should show that the decision was incorporated before execution continued.
Turn decisions into bounded precedent
A useful decision record includes its scope and review trigger.
“Managers can invite members” may apply only to one product tier, organisation type, or current authorisation model.
Without those limits, the next agent may treat the decision as a universal rule.
Store:
- where it applies;
- what assumption supports it;
- who owns it;
- when it was last verified;
- what event requires revalidation.
This preserves product ownership without turning every answer into permanent policy.
How paqad-ai uses decision packets
paqad-ai’s feature-development workflow is designed to categorise human decisions, pause execution, prepare a packet,
record the response, and resume with durable state. The answer becomes part of the evidence and future context.
The model still does useful work. It gathers, compares, and recommends.
The human still owns the consequence.
Decision packets make that boundary faster and clearer than either constant supervision or a final rubber stamp.
Install paqad-ai: https://github.com/Eliyce/paqad-ai/
Source notes
- NIST AI RMF Playbook, Measure, voluntary guidance on
oversight and accountable decisions. - Product mechanism: first-party details from the current Eliyce/paqad-ai repository.