meeting-confirm call outcomes
Outcome contract
MeetingConfirmRecord receives callId, result and message. The message must be non-empty after trimming and at most 1000 characters.
The agent also gets the meeting facts, the call start as ISO with its offset and the configured time zone, and the transcript as untrusted data. The facts payload carries the meeting ID, the title, today's date and the start, both written out in the call language and time zone, the time zone, the contact (the name from the deal note, otherwise the customer company) and the salesperson's name.
The result values are:
confirmedandcancelled, with no extra field.reschedule, with requiredpreferredTimeof 1 to 500 characters.callback, with required offset ISOat.other_person, with required offset ISO or nullreachableAt.unclear.
Invalid arguments return an explicit tool error for retry. The tool accepts only a call bound to its current conversation and records a verdict once, so a repeat call cannot change it. Each agent result carries its own message, validated by the plugin's Zod contract, and the existing scheduling rules decide whether a callback or reachable time permits another attempt.
Note and notice formats
The Raynet note line is <ISO timestamp> <agent message> [Elowen #<attemptId>], using the persisted result time. Teams receives that exact message followed by one reference line:
The customer requests Friday afternoon. Please contact them to agree on the next step.
#42 · Oct 8, 2026, 2:00 PMNo second model extracts or summarizes the call.
Timeouts and fallback
If the agent finishes, fails, is stopped or cannot start without recording, the plugin records unclear immediately. A turn that never settles, including one interrupted by a daemon restart, has a persisted ten-minute deadline.
The fallback writes the unclear tag and label to Raynet, and Teams receives the existing company-prefixed unclear label with the reference line. The delivery loop is the only external writer.
Contact lookup contract
The plugin reads the deal note (description, usually HTML) and asks the Utility model for the customer's contact. The model receives the meeting title, the customer company and the salesperson's name as context, and the note as untrusted data.
It returns {name, phone}, each value a string or null. The phone must be written exactly as in the note. The model returns null when no number belongs to the customer or it is unclear which one does, and must never return the salesperson's or a colleague's number. An answer outside that shape fails the meeting loudly and nothing is dialed.
The answer is kept on the job with a hash of the note and the meeting context, so the model reads a note again only when it or the context changes. Without a utility model the job stays pending and discovery retries; nothing is guessed. The extraction runs outside any account, so its cost is not charged to the service account's spend limit.
Phone normalization and outages
Discovery reuses the persisted normalized phone only while the contact hash and the raw phone are unchanged. It still refreshes the meeting, owner and deal note, and every call attempt performs a fresh lookup before dialing.
The phone control separates invalid numbers from lookup outages. An outage clears the prepared phone and leaves the job pending for discovery without marking the contact invalid. A normalized +421 number selects Slovak; any other number selects Czech.
Core refusals do not consume an attempt. They raise an administrator alert and retry no sooner than five minutes, inside calling hours; when no slot remains, the job closes as unreachable.
Single service and timer
One service owns discovery, deliveries and calls. Its single timer wakes at the next due instant, capped at one hour, and discovery wakes it for newly found work. One call runs at a time.