Structured Outcome Followup Call

Structured Outcome Follow-up Call

What this skill does

Many phone-call workflows aren't really "have a conversation" — they're "call someone, get a small set of specific answers, decide what happens next based on those answers." This skill packages that pattern for CALL-E:

place call (goal-driven task + resultSchema)
    -> CALL-E adapts the conversation to gather the answers
    -> webhook returns structured answers
    -> your rubric scores them deterministically
    -> a follow-up action fires based on the score

It is not a specific workflow like a reminder call or an appointment booking call — it's the reusable scaffolding underneath any workflow that follows the shape above. Bring your own questions, your own rubric, and your own follow-up action; this skill handles the call lifecycle, the provider abstraction, and the safe-to-develop-without-a-live-call part.

Status

Reference implementation, mock-mode-first. scripts/mock_provider.py simulates CALL-E completely (no network calls, no credentials) so you can read, run, and adapt this skill before ever touching a live CALL-E account. scripts/orchestrate_example.py is a complete, runnable, non-healthcare example (a delivery-exception follow-up call) that exercises the whole pattern end to end using the mock provider.

A real-CALL-E adapter is intentionally not included in this first contribution — see "What's deliberately left out" below.

When to use this skill

Use this when you're building an agent that needs to:

• Ask a small number of specific questions over the phone (not an open-ended conversation)
• Turn the answers into a decision using rules you can write down and explain
• Take an automatic next step for some outcomes, without a human reviewing every call

Don't use this for open-ended conversational calls, calls where the "right" response can't be reduced to a rubric, or anything where the follow-up action needs a human judgment call before firing (see the safety checklist for where that line is).

How it works

1. Define your questions and result schema

from structured_call import CallQuestion

questions = [
    CallQuestion(key="package_received", prompt="Did the package arrive at the address?"),
    CallQuestion(key="condition_ok", prompt="Was the package in good condition?"),
    CallQuestion(key="reschedule_needed", prompt="Does delivery need to be rescheduled?"),
]

scripts/mock_provider.py turns this list into both a natural-language task description for CALL-E's goal-driven call model and a JSON resultSchema, the same way described in references/result_schema_guide.md.

2. Write your rubric

A rubric is just a function: structured_answers -> (level, score, reasons). It's intentionally not part of this skill's code — your rubric is domain-specific and you should be able to read it top to bottom without touching the call machinery. See assets/example_rubric.json for the delivery-exception example's rubric, expressed as data so it's easy to adapt without writing a new scoring function from scratch.

3. Run it

python scripts/orchestrate_example.py

This runs the full pipeline against the mock provider and prints the outcome for each of three canned scenarios (no issue / minor issue / needs reschedule), so you can see the shape of the whole thing before wiring up anything real.

4. Swap in a real provider (not included yet)

Everything in scripts/mock_provider.py implements one small interface (initiate_call, parse_webhook_event) — a real CALL-E adapter is a second implementation of that interface, not a rewrite of anything else. This keeps today's contribution runnable and inspectable without requiring reviewers to have CALL-E credentials to evaluate it.

What's deliberately left out (and why)

• No real CALL-E network calls. Keeping this contribution mock-only for now means anyone can clone, read, and run it in under a minute with zero setup — which is worth more to the community than a live adapter that only some contributors can verify. A real adapter is a natural, small follow-up contribution once this pattern itself has been reviewed.
• No specific domain logic (healthcare, delivery, HR, etc.) baked into the skill itself — only in the example. The skill is the scaffolding; the example is one illustration of it.
• No notification/paging integrations. The example's "follow-up action" is a printed log line, matching this repo's own guidance to keep examples safe-by-default.

Files

structured-outcome-followup-call/
├── SKILL.md
├── scripts/
│   ├── mock_provider.py        # Standalone mock CALL-E client + orchestration loop (stdlib only)
│   └── orchestrate_example.py  # Runnable, non-healthcare worked example
├── references/
│   ├── result_schema_guide.md  # How to write a resultSchema CALL-E can reliably fill
│   └── safety_checklist.md     # Consent, idempotency, phone formatting, credential & action boundaries
└── assets/
    └── example_rubric.json     # The delivery-exception example's scoring rubric, as data

See also

references/safety_checklist.md before adapting this to any real workflow — in particular the note on where automatic follow-up actions should and shouldn't be allowed to fire without a human in the loop.