> ## Documentation Index
> Fetch the complete documentation index at: https://docs.agentium.in/llms.txt
> Use this file to discover all available pages before exploring further.

# 8. Prepare to ship

> Turn the local tutorial into an application with explicit ownership and failure behavior.

[Support assistant tutorial](/learn/support-assistant)

You now have the building blocks: an Agent, read tools, conversation state, retrieval, approval, streaming, and an HTTP boundary. Deploying them requires decisions about your application's users, data, and operations.

## Define the contract

| Decision | For the support assistant | Verification |
| - | - | - |
| Identity | Derive the customer from verified credentials | A forged body `userId` cannot change the caller |
| Resource ownership | Bind sessions, orders, and approvals to that customer/tenant | Customer B cannot read customer A's order or conversation |
| Persistence | Choose stores for history and any longer-lived tasks | A controlled restart has the documented effect |
| External writes | Use the payment service's idempotency and reconciliation | A retry does not issue a second refund |
| Cancellation | Decide which work belongs to the client connection | A disconnect stops connection-owned work |
| Quality | Check successful status, tool behavior, and answer evidence | Unknown orders and absent policies fail predictably |

## Build a small evaluation set

Include the prompts you tried in this tutorial: a known order, an unknown order, a follow-up in the same session, a follow-up in a different session, a supported policy question, an unsupported question, and both approval outcomes.

Assert the underlying effect and retrieved evidence where possible. For the approval case, the refund counter is a better contract than a substring in the model's answer. For a real provider, pin the model configuration and record it with the evaluation results.

[Evaluation](/eval/overview) covers suites and scorers. [Troubleshooting](/reference/troubleshooting) helps distinguish an execution failure from an answer-quality problem.

## Decide what needs recovery

Conversation persistence preserves history. Queue redelivery schedules another attempt. A checkpoint captures state. None of these alone knows whether a payment provider already accepted a request. Choose the [recovery contract](/ship/recovery) before enabling automatic retries for writes.

## Continue by task

<Columns cols={2}>
  <Card title="Authenticate and authorize" icon="lock" href="/ship/authentication">Bind execution to verified identity and resource ownership.</Card>
  <Card title="Plan recovery" icon="rotate" href="/ship/recovery">Choose history, queues, or durable tasks for the actual failure.</Card>
  <Card title="Operate the application" icon="chart-line" href="/ship/operations">Set budgets, collect traces, handle shutdown, and investigate errors.</Card>
  <Card title="Choose more structure" icon="diagram-project" href="/learn/choose-an-approach">Add a harness, workflow, or team when a concrete requirement calls for it.</Card>
</Columns>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.