Approvals & decisions
When a selected company package needs your sign-off, it should expose the pending decision through its API or operator interface. Here’s how the canonical software-company package’s approval flow can work and how to think about pushing back.
What triggers an approval
The reference package surfaces decisions when they cross a line into territory only you can handle. Concrete examples:
- Spending above a threshold — A team wants to commit budget beyond its approval limit. Comes to you.
- External commitments — A new promise to a customer, partner, or vendor that binds the company to a specific outcome.
- Brand-touching decisions — Public-facing messaging, customer-facing positioning, anything that affects how the company is perceived.
- Structural changes — A team wants to take on a new mandate, or split, or retire. A new component desire is proposed. A new persistent agent is proposed.
- Strategic moves — Bets that change what the company is for or how it allocates effort.
- Promise breaches — When the company won’t be able to keep a prior commitment, the closure (renegotiation, repair, or explicit breach) needs your input.
In this package, approval can be configured per team and mandate. If something is surfacing to you that shouldn’t, tell the CEO — the threshold probably needs adjusting.
Where approvals show up
Approval records belong to the package that defines them. That package may expose an inbox UI, notifications, or API commands. A useful interface identifies the requesting principal, proposed action, context, and the available decisions: Approve, Reject, or Request revision.
What each decision does
- Approve — The agent proceeds with what it proposed. The approval is recorded with your identity and the time; it becomes part of the audit trail.
- Reject — The agent doesn’t proceed. The proposed action is killed, with the rejection recorded. The agent knows it was rejected and adjusts its picture of the situation. The underlying work item may stay open if there’s still something to do; a rejection doesn’t automatically cancel the work, just this specific way of doing it.
- Request revision — The agent should rework the proposal and come back. Use this when the direction is right but the specifics need adjustment — the budget number is off, the messaging is close but not quite, the scope should be wider. Include a comment so the agent knows what to change.
How to think about pushing back
Rejecting and asking for revisions aren’t failures of the agent — they’re how the company learns your taste. A useful rule of thumb:
- Approve — When the proposal matches your direction and you have no specific objections.
- Request revision — When the direction is right but the specifics are wrong. The agent should iterate.
- Reject — When the proposal shouldn’t happen at all in this shape — the agent has misread the situation or the team’s mandate is wrong for this work. After rejecting, consider whether the mandate or the direction needs updating so the next similar situation doesn’t produce the same proposal.
Why this package omits bulk approval
The reference package asks you to consider each approval. If you find yourself wanting to bulk-approve, that’s a signal that either (a) the threshold for surfacing decisions is too low and should be raised, or (b) the team’s mandate isn’t carrying the right authority. Both are fixable. Bulk-clicking through approvals is the wrong response.