Define proof before an agent says an action is done

Write the claim you intend to support

Before execution, decide what the user needs to know and which evidence would support that statement. An email send response can establish provider acceptance, not human reading. A call creation acknowledgment can establish that dialing was requested, not that a conversation occurred. A browser screenshot can show a visible page, not every downstream system change. This discipline helps the agent return a useful result without inflating a narrow technical acknowledgment into a broader claim of real-world success.

Use returned identities and states

Save the actual message, operation, session, run or call ID returned by the server. Associate it with the approved request and preserve the structured state. An action proposed in a model response is not executed work, and a pending approval is not a completed action. If the server returns a resource after recovering an earlier accepted attempt, record that as recovered evidence rather than a second fresh execution. Avoid reconstructing the result from the original arguments, which describe what you wanted rather than what the provider reported.

Report email evidence precisely

Lupin email.sent means the outbound provider accepted the message. Current outbound adapters do not automatically wire recipient delivery receipts, so an agent must not assume email.delivered will follow every send. An open-tracking observation also does not prove a named human understood the email. Keep local policy rejection, provider rejection, accepted submission and uncertain outcome separate. A draft created successfully should be described as ready for review, with no outbound message implied. The same evidence vocabulary should appear in your dashboard and the agent’s natural-language reply.

Use diagnostics as supporting evidence

Agent traces can correlate observed input, selected context, model output, tool spans, approvals and API/provider activity. They are operational diagnostics, not a signed authorization ledger or a tool replay interface. Missing traces can reflect background-export loss, so absence is not proof that an action never occurred. Timings can overlap and should not be added as though they were consecutive stages. Use operation journals and provider receipts as the authority for action outcome, then use traces to understand why the agent chose or described that action.

Keep unknown outcomes visible

If a provider result is uncertain, say so and preserve the saved operation key. Do not turn the uncertainty into a confident completed message to make the interaction feel smoother. The user benefits from knowing that reconciliation is needed before another send, call or app write is attempted. Likewise, missing measurement should appear as not measured or not reported, not zero. An agent that admits the actual evidence boundary makes recovery possible; an invented success can cause the user to act on a message that was never confirmed.

Review completion phrases with fixtures

Create a small table of returned states and allowed wording in your application tests. Include a draft, accepted email, rejected request, uncertain provider outcome and missing telemetry. Your next step is to review one real completion template per tool family and remove any claim that requires evidence the tool does not return.

Sources & verification

Reviewed against checked-in Lupin API handlers and documentation. Example requests were not executed against live providers.

• Lupin MCP result semantics ↗Checked 2026-11-05
• Lupin email event evidence ↗Checked 2026-11-05
• Lupin client capability boundaries ↗Checked 2026-11-05

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.