Make software that agents can use
Give outside agents clear operations, bounded authority and reliable results, so they can use your product without you losing control.
An outside agent wants to use your product for a customer. How do you let it work without losing control of what it does? Let it discover what it may do. Check who is asking at the moment it acts. Preview a consequential change, commit it once, and report what actually happened. Design this beside the human interface.
Discover: offer operations with clear limits
Document inputs, required permissions, side effects, limits and error behaviour. Offer a business operation such as "create inspection request", not open access to the database. Say which operations only read and which make commitments.
Authorize: check who is asking, when it acts
Keep the customer, the user, the agent and the task identifiable. The product checks the delegated permission at the moment the operation runs. A tenant is one customer organisation's separate space in your product. A tenant identifier sent by the caller is not proof that the caller may access that tenant. Keep sensitive content out of error messages and diagnostic traces. The delegation chain shows how the person's identity travels with the request.
Preview: validate a consequential change
For a change that commits money, data or work, offer a preview first. The preview checks the change without making it. Changes that move money or create a formal record sit in the deterministic zones. There a fixed rule or a named person decides, not the agent.
Commit: run it once, even on a retry
Return an operation identifier for a long-running job. Provide a documented status check, rules for cancelling, and a way to hand the work over and resume it. Make retry behaviour explicit. A repeated request must not quietly create another purchase, payment or inspection.
Confirm: report what actually happened
Return a receipt with the operation, the affected record identifiers, the status and any remaining conditions. Keep accepting a job separate from completing it. When a task is handed to a person, show the evidence, the current state, the open questions and the choices.
Make agent use operable
Publish limits and how use is counted and billed. Test wrong inputs, expired permissions, partial failures, duplicate requests and access across customers. Include example integrations. Add a skill, a small package of instructions for agents, only when it helps them use the product correctly.
Choose the simplest interface that works
A clear existing API may be enough. A tool protocol is a standard way for agents to find and call operations. It helps discovery and calling, but it does not replace authorization, transaction design or support ownership. Your own agents reach products like yours through a tool gateway, where enforcement outside the model happens. See the tool gateway decisions and the integration fabric layer (R03).
Evidence and limits
These are design questions, not measured results. Test each pattern within your own product. Tool protocols for agents are still changing.
Next step
Follow one agent task from request to confirmed result on follow one inspection task.
Cite this page
Written by Murali Sid, Founder and AI Systems Architect, last updated 15 October 2026. Licensed CC BY-SA 4.0, so quote it freely with attribution.
Murali Sid (2026). Make software that agents can use. Agentic Architecture Skills. https://www.agenticarchitectureskills.com/architecture/software-for-agentsMachine-readable version of this page: /architecture/software-for-agents.md
The concern matrix
Ten requirements every layer must honour, such as identity, privacy and cost. For each one: which layer owns it, which layer stops a violation, and the six gaps with no complete answer yet.
Plain words
The glossary: every technical term in this guide in one plain sentence, grouped by theme, with a link to the page that explains it.