# 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. Author: Murali Sid (https://linkedin.com/in/muralisid) Source: https://www.agenticarchitectureskills.com/architecture/software-for-agents Published: 2026-09-17 Updated: 2026-10-15 Licence: CC BY-SA 4.0, https://creativecommons.org/licenses/by-sa/4.0/ Cite as: Murali Sid. Make software that agents can use. Agentic Architecture Skills. https://www.agenticarchitectureskills.com/architecture/software-for-agents --- 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 [#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 [#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](/architecture/delegation-chain) shows how the person's identity travels with the request. ## Preview: validate a consequential change [#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](/architecture/deterministic-zones). There a fixed rule or a named person decides, not the agent. ## Commit: run it once, even on a retry [#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 [#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 [#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 [#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](/architecture/enforcement) happens. See the [tool gateway decisions](/decisions) and the [integration fabric layer (R03)](/layers/r03-integration-fabric). ## Evidence and limits [#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 [#next-step] Follow one agent task from request to confirmed result on [follow one inspection task](/architecture/task-walkthrough).