Support desk

​

What this example demonstrates

1. Verify each incoming support message in your service, then send it to the one Session you keep for that ticket conversation. Your service owns the ticket-to-Session map.
2. Project the Session event log into the support UI instead of maintaining a second transcript.
3. Expose ticket functions as Custom tools declared on the Agent. ActionPolicy chooses allow, require_approval, or deny for each call, and a required ActionApproval records the exact human decision on the frozen call.
4. Run the handler in the support application. Approval is not execution: an approved call still waits until the application checks its own tenant, account, and ticket access, runs the handler, and returns the correlated result. A call for a ticket the caller cannot reach is refused there, by the application.
5. Keep connected tools on their own path. A tool that acts through a Connection (for example, sending email through a provider account) is checked against governed account access, policy, and any required approval, and executes inside Checkfu’s trusted provider boundary rather than in the support application.
6. Deliver accepted Session output downstream from your service. Provider acknowledgement is not Checkfu custody, and provider redelivery is not a new Agent turn unless the message key is new.

Support provider
  │ verified message
  ▼
Your service
  │ POST /v1/sessions/{id}/events, read events, deliver replies
  ▼
Session → Run → durable event log
  │
  ├── Custom tool call → ActionPolicy → ActionApproval (if required)
  │     → support application: ticket access check → handler → result
  └── connected tool call → account access → ActionPolicy → ActionApproval (if required)
        → provider execution inside Checkfu

​

Retention, erasure, and support boundaries

​

Pinned source boundary

	defineTool({
		name: "close_ticket",
		description: "Close a resolved support ticket after a human approves the frozen call.",
		schema: ticketIdSchema,
		needsActionApproval: true,
		handler: (input: JsonValue, context: TicketExecutionContext) => {
			const { ticket_id } = readTicketArguments(input)
			return ticket_id === ticketId
				? actions.closeTicket({ ticket_id: ticketId }, context)
				: {
						ok: false,
						error: "ticket_scope_mismatch",
						ticket_id,
						expected_ticket_id: ticketId,
					}
		},
	}),

​

What this example omits