Faster code and autonomous execution change how systems are built. They do not remove the need for clear permissions, recoverable actions and someone accountable after launch.
Business leaders are being pitched AI agents that can research a customer, prepare a quote, update a system and handle the follow-up. The demonstrations can be convincing. Give the agent a goal, watch it use a few tools, and work that once took several steps appears to finish in minutes.
Then the demonstration meets the business. A document contains conflicting instructions. The customer already exists under another name. An integration times out after accepting an update. Nobody knows whether the agent should retry, stop or ask for help.
That is where a promising prototype starts to feel fragile. The missing pieces are often the operating decisions around the model: what it may change, how it confirms a result and who handles an exception.
For an organization considering custom software or agentic development, those decisions belong in the initial scope. They determine whether the system becomes useful infrastructure or another tool employees must constantly supervise.
Two changes are happening, and they need different controls
First, AI can help developers build conventional software. It can draft code, explain an integration, suggest tests and accelerate revisions. The resulting application may still follow a prescribed sequence every time it runs.
Second, an application can give an AI model a goal and tools, then let it choose parts of the execution path. It may decide which records to retrieve, which question to ask next, whether a result is sufficient and when to try another approach. That is a change in runtime behavior, not just a faster way to write code.
Traditional custom software generally expresses decisions through explicit rules, application logic and database operations. Those systems can still fail, but their intended paths are specified. An agent introduces probabilistic judgment into the path: its next action depends on the model, the available context and the results it observes.
Anthropic distinguishes predefined workflows from agents that dynamically direct their process and tool use. Its guidance also recommends starting with the simplest approach that meets the need. That is a useful architectural distinction, rather than a reason to make every workflow autonomous.
A fixed calculation, permission check or transaction rule usually needs explicit software enforcement. Interpreting an unevenly written request or deciding what additional evidence to gather may benefit from an agent. A dependable solution can combine both.
Authorization has to survive a persuasive request
Consider an illustrative order-entry workflow. An agent reads a customer's email, identifies products, retrieves account information and prepares an order for review. That is a useful, bounded assignment.
It should not gain permission to change credit limits, alter payment instructions or release a shipment merely because those actions would help it finish. A customer email, attached PDF or retrieved webpage is evidence to evaluate. It is not an authority that can expand the agent's access.
Define the identity under which the agent works, the customer or tenant whose records it may access, and the specific operations each tool permits. Enforce those decisions in the service and database, where the action actually occurs. A sentence in a prompt cannot substitute for an access check.
Keep safeguards independent of the agent's judgment. The agent can propose an action; the surrounding system must decide whether that action is authorized, valid and within its allowed scope. Credentials should remain in approved secret storage, outside generated content and routine logs.
Data security also includes what leaves the environment. Identify which documents, prompts, attachments and tool results reach model providers, what retention settings apply, and how access is removed when a person or customer leaves. Give the workflow the information it needs for its assigned task.
A timeout does not tell you whether the work happened
Suppose the agent submits the approved order and the connection fails before a response arrives. The order may exist. Sending the same instruction again could create a duplicate.
The system needs a durable operation reference, a record of the attempt and a way to reconcile the receiving system's result. Where the destination supports it, an idempotency key lets a retry refer to the same operation. Stripe's API documentation provides a concrete example of this retry mechanism; each integration's actual guarantees and retention limits still need checking.
When a result remains uncertain, the workflow should enter a visible reconciliation queue. An employee needs to see what was requested, which evidence is available and which actions are safe next. A generic failure message provides little help.
Put limits on retries, execution time and spending. Define when a partial result can be reversed, when a correcting transaction is required, and when a person must decide. External messages and completed transactions often cannot be undone by restoring a database backup.
This work is easy to miss in a demonstration because the happy path moves quickly. In production, handling uncertainty is part of the product.
Who owns the software after the agent writes it?
AI-generated code still needs a repository, review history, tests, deployment instructions and maintenance. Someone must understand the dependencies and be able to change the system when an integration or model changes.
Ask what the business receives at handoff: source code, database deployment scripts, configuration inventory, evaluation cases, operating documentation and an exercised recovery procedure. Identify who controls the repository, hosting accounts and production credentials.
Put the agreed rights to custom deliverables and any third-party components in the engagement terms. Clarify how business data is exported, how vendor access ends and what support is included. Do not assume that access to a working screen answers those questions.
JWA's discussion of software ownership after launch separates business, technical and data ownership. That remains a useful set of questions when an AI assistant produces part of the implementation or an agent operates part of the workflow.
Name both a business owner and a technical owner. The business owner defines acceptable outcomes and exceptions. The technical owner maintains the application, evaluates changes and leads incident response. Delivery is incomplete if everyone assumes the other party is watching it.
A practical scope starts with one useful task
A business leader does not need to arrive with a model selection or a finished architecture. A clear description of the work, the systems involved and the mistakes that matter is a stronger starting point.
- Choose one complete workflow. Define its starting event, expected result and responsible team. For the order example, begin with preparing an order for review. Expand its authority only when evidence supports doing so.
- Make correctness observable. Specify the required fields, approved sources, calculations and checks. Include examples with missing information, conflicting documents and requests outside scope. A confident explanation is not proof that a record is correct.
- Write the action boundaries. Separate what the agent can read, draft, change and send. Identify customer boundaries, approval requirements and the conditions that require a handoff.
- Design the exception path. Decide what happens after a timeout, duplicate request, unavailable service or ambiguous result. Give the review queue an owner and retain enough evidence to resolve the case without exposing secrets.
- Set release gates before the demonstration. Require representative evaluations, permission tests, integration checks and a recovery exercise. Begin with limited exposure and human review. Recheck the workflow when models, prompts, tools or source data change.
- Measure the whole cost. Compare completion time, correct outcomes, review effort, exceptions and operating cost with the current process. Include model usage, support and maintenance. Faster drafting means little if employees spend longer repairing the result.
Human handoffs should be deliberate and usable. Show the reviewer the proposed action, supporting information and unresolved issue. Place approval before an external commitment, and ensure the approved action is the one that executes. A vague confirmation dialog can create the appearance of oversight without providing much control.
Build for the day after launch
JWilliams & Associates has built enterprise software since 2006. AI changes the speed of implementation and creates new ways to handle work that resists a fixed script. It also raises the importance of contextual judgment, independent safeguards and clear operational ownership.
Agents can work. The business needs to know where they can act, how their results are checked and who takes responsibility when the situation falls outside the plan. Those answers should be visible before the system is asked to carry real operational weight.
If your roadmap includes custom software or AI agents, bring one workflow, your existing systems and the outcomes you need to JWilliams & Associates. We can evaluate where conventional software fits, where an agent can add value, and what it will take to own and operate the result after launch.