AI in application systems
Choose the right shape for an AI feature
Compare a model call, a retrieval workflow, and a tool-using agent. Make cost, evidence, and control part of the design from the start.
Before choosing a model or agent framework, write down what the application must decide, what it may change, and how you will know the result is useful.
Consider a fictional maintenance request: “The meeting-room display disconnects after ten minutes.” The system could classify the request, find an approved troubleshooting guide, or investigate several systems. Each task needs a different amount of freedom.
Alternative patterns for the fictional maintenance assistant. Each sits behind application-owned access checks and usage limits.
Read the flow
- Classification: constrain the input, call the model, then validate the category.
- Retrieval: select permitted evidence, draft from it, then check the claims and source revisions.
- Agent: propose a step, pass application authorization and any required approval, then execute a narrow tool. Feed its result back only within the task's limits.
1. Choose the smallest useful execution path
| Need | Starting design | What to verify |
|---|---|---|
| Classify the request | One model call with an allowed category list. | Reject unknown categories; measure misrouting. |
| Suggest a documented fix | Retrieve permitted documents, then draft with source references. | Can the cited passage support each instruction? |
| Investigate an unclear fault | A bounded agent that chooses among diagnostic tools. | Does it stop, ask for help, and stay within its access? |
A workflow follows paths chosen in application code. An agent can choose its next tool or step from intermediate results. That flexibility introduces additional decisions to evaluate. Anthropic describes this distinction in Building effective agents.
2. Put the model behind an application boundary
Keep provider credentials and model calls on the server. Give the application a small contract: permitted input, expected result, source references, and an explicit failure outcome. Validate structured output before another component consumes it. A correctly shaped response can still contain incorrect facts.
For retrieval, apply the user's document-access rules before selecting evidence. Store the document identity and revision with the result so a reviewer can find the supporting text. Retrieved content is evidence, not permission to change the application's instructions or invoke another tool.
3. Separate a suggestion from an action
In this example, reading a troubleshooting guide and restarting a room device have different consequences. Expose them as separate operations. The server checks authorization for each call; a model's proposed device ID cannot grant access. If a restart requires approval, bind that approval to the chosen device and operation, and invalidate it when either changes.
4. Compare models on the same cases
Use a small set of permitted or synthetic requests: a clear fault, missing device details, contradictory documentation, an inaccessible document, and a tool timeout. Compare task completion, unsupported instructions, latency, and cost per completed request. Choose a model using these results instead of assuming the newest or largest model is the best fit.
Set limits for input size, output tokens, elapsed time, tool calls, and retries. Record the final outcome separately from a successful API response. A useful fallback might ask for the device model; it need not produce an answer for every request.
Implement classification first. Add retrieval only if classification cannot solve the task. Introduce an agent loop when variable diagnostic steps justify the extra complexity. Re-run the same cases after each change.