Outcome Completion Agent

Outcome Completion Agent

Use this skill when the user states an outcome rather than a call, the route to that outcome runs through more than one organisation, and the next organisation is usually named on a call rather than known in advance.

"Get a replacement pallet for the crushed delivery on order BK-7741, before Friday, under $500."

The user has one phone number: the supplier who sent the broken pallet. The supplier is out of stock and names a distributor. The distributor quotes over the limit and names its own depot. The depot can do it. Three organisations, two of which did not exist as far as the agent was concerned when the run began.

outcome-completion-agent is a calling-pattern skill. It adds no backend, no queue and no daemon. It turns one authorized "make this happen" request into a bounded loop of one-off CALL-E calls whose order is decided by what earlier calls established.

When To Use

• a problem whose owner is unknown: "find out who can actually fix this and get it fixed"
• a chain of custody: supplier to distributor to depot, carrier to facility to counter, insurer to provider to adjuster
• a goal with a hard limit attached — a price ceiling, a date, a required reference — where a cheerful "yes" that breaks the limit is a failed outcome
• any request where the honest answer to "who should we call?" is "ask the first person"

When Not To Use

• one call, one structured answer. Use a single-call skill; this loop is overhead.
• a known, priority-ordered candidate list for one opening. Read skills/priority-call-waterfall/SKILL.md instead — one opening, call in order, stop at the first yes.
• comparison shopping over an enumerable set of same-service vendors (every barber within 4km). If the candidate list is a database or map query, the frontier does not need to grow and this skill's machinery buys nothing.
• anything email, a web form, or an API can do. A phone call is a real-world side effect and the most expensive way to ask a question.
• goals with no completion test. If nobody can say what "done" looks like, the loop cannot stop, and a loop that cannot stop must not be given a phone.

Core Workflow

1. Confirm the user wants this pursued by phone, now, and that they accept calls may go to organisations they did not name.

2. Collect the outcome fields (see Required Fields). Ask for anything missing. Never infer a phone number, a price ceiling, or a deadline.

3. Show a masked preview: the goal, the constraints as the agent understood them, the starting phone book, and the call budget. Get explicit confirmation before call one. Always show the parsed constraints back. A price ceiling that failed to parse is a ceiling that will never block anything, and the user is the only one who can catch it.

4. Loop, one call at a time:

   plan -> (approval, if it commits) -> one call -> evidence -> constraints -> plan

   • plan — pick the next party from the frontier: a party never called, else a party that did not answer and is under its retry cap. Prefer a party named by the call that just happened over one the user listed but nobody has reached.
   • call — exactly one CALL-E call, with a structured result schema. Wait for a terminal status. Read references/evidence-schema.md for the schema every call fills.
   • evidence — record what was established: verdict, facts, blockers, referrals, and any concrete offer. Add referrals with a valid E.164 number to the frontier. Drop referrals without one.
   • constraints — evaluate any offer against the user's limits. Read references/constraint-evaluation.md. A call that completed happily and breaks a hard limit is a failed outcome: keep working.

5. Stop conditions, checked before every dial:

   • an acceptable offer has been confirmed by the other party → resolved
   • the call budget or the per-party cap is reached → stop and report
   • every lead is exhausted with nothing acceptable → stop and report

6. Exactly one call in the run may commit the user, and only after they approve it. Read references/approval-gate.md.

7. Report using the Output Format below, whether or not the goal was reached.

Required Fields

• goal — one sentence, imperative, with the constraints taken out of it
• constraints[] — each with kind, description, value, and hard (budget · deadline · required_fact · preference · forbidden). hard: true disqualifies an offer. hard: false only ranks it.
• organizations[] — the starting phone book: name, phone (E.164), role. One entry is enough; that is the point of the skill.
• budget — max_calls for the whole outcome and max_calls_per_org. Both are required. A goal-seeking agent with an unbounded phone budget is not a product, and CALL-E accounts are metered.

Phone numbers must be E.164, and must be masked in every summary, preview and report.