Start small.
Make the contract clear.

1. Choose a reviewable first task

Pick something with a clear input and an outcome you can inspect. Summarizing a short approved document or extracting a supported field is a better starting exercise than automating a whole department. Write down who uses the result and what happens when it is wrong.

Use the ecosystem map to choose your track. The foundations guide explains the distinction between a model, an API contract, and a hosted service. That distinction keeps a polished prototype from being mistaken for an operational product.

2. Describe success and absence

Write one accepted example and one rejected example before adjusting a prompt. Include an input with missing information. Decide whether the correct response is an unavailable state, a request for clarification, or a result that must be reviewed. Do not require the model to fill a field that the evidence cannot support.

Keep the consumer in view

A sentence for a person and a record for another system need different contracts. Use a schema when the consumer requires structure, then add checks for meaning and evidence. Parsing successfully should not be the only acceptance criterion.

3. Inspect a reference pattern

Open the Pattern Lab, select the closest pattern, and read its companion guide. The examples are local JSON fixtures. Copying one does not create an API connection or start a remote process. The pattern pack includes all six contracts and their explicitly labelled example results.

These patterns are provider-neutral design material. Field names do not claim compatibility with every AI provider. Use the primary-source directory to find the actual contract for the service or library you choose.

4. Put authority in the application

For a real integration, use controlled application code to authenticate users, enforce permissions, hold private credentials, validate responses, and manage review. A public static page cannot safely hide a provider secret from its visitors. Do not paste private keys into the reference examples or add them to a public repository.

Treat model-generated tool calls as proposals. Check the exact operation and target before execution. Use separate approval for consequential writes, and preserve the distinction between an accepted request and a confirmed outcome. The security guide collects these boundaries in one place.

5. Test the whole path

Exercise an ordinary result, missing evidence, conflicting evidence, a validation failure, and an unavailable service. For tools, add a permission denial and an uncertain write. Record the expected user-facing state for each. An elegant success path is only part of the interface.

Keep prompts, schemas, retrieval configuration, and evaluation fixtures versioned. Compare changes against the same task criteria. Inspect whether an apparent cost saving caused more retries or rejected outputs before calling it an improvement.

6. Add complexity only for a reason

Retrieval, durable memory, routing, and autonomous tools each introduce new decisions. Add the next layer only when it solves a measured problem in the smaller workflow. Some tasks should remain draft-only or approval-based indefinitely.

A good first milestone is a small system whose errors are visible and whose next action is understandable. When another person can explain what the interface does, what it cannot do, and how to recover from a failure, you have something worth extending.