Smarter Software. Bigger Possibilities. Greater Consequences When It’s Built Wrong.

Your next application could spot a margin problem before a quote goes out, turn scattered documents into a useful review, or give employees back hours spent moving information between systems. Modern intelligent development makes those possibilities worth taking seriously.

The uncomfortable question comes when that application starts changing records people rely on. What prevents it from applying a correct calculation to an outdated quote, exposing private information, or repeating an order after a timeout? A convincing demonstration does not answer those questions. The architecture has to.

The upside is real, and it is specific

Most conversations about AI in business software start with capability. The more useful starting point is capacity.

A team that spends its week rekeying purchase orders, reconciling quotes against a supplier's new price file, or tracking down why a commission check came out wrong is not short on skill. It is short on hours.

Reducing repetitive handling can give experienced staff more room for decisions that need their judgment. The business case should measure that improvement against the current process: time spent preparing a review, corrections required, and how quickly an exception reaches someone who can resolve it.

Agentic development adds another opportunity on the engineering side. GitHub’s agent guidance describes tools that can inspect code, prepare changes, run checks and assist with reviews. It also warns about inaccurate or insecure output and the need for human review. Useful automation can expand what a development team attempts; whether it improves delivery has to be demonstrated on the actual work.

Both layers are worth having. Neither substitutes for deciding what "correct" means at your company.

Where the consequences actually live

The risk grows when software changes money, inventory, sensitive information or a customer commitment. Failures can be quiet: a plausible value may pass from one system to the next before anyone notices it is wrong.

Four areas deserve explicit attention:

• Money. A price, a margin, a commission, a cost — numbers that later become invoices, payroll and filings.
• Inventory. What exists, where it sits, what it is committed to — numbers that become promises to a customer.
• Commitments. A quote, a ship date, a change order — statements another party is entitled to rely on.
• Private information. Customer records, employee details and commercial terms that must stay within the right access boundaries.

These records outlive the moment that created them. A clearly failed transaction invites investigation. A plausible but incorrect one may continue through purchasing, fulfillment or finance. Detection therefore has to check the business outcome as well as whether the application stayed online.

Two kinds of agent, one important difference

The word "agent" now covers two jobs that should never be blurred.

Agents used in development help engineers make software. They can investigate a repository, propose changes, prepare tests and explain a diff. Their work still needs requirements, review and acceptance evidence before release.

Agents inside business applications help complete workflows. They may read information, prepare a recommendation, or use approved tools to change a record. Permission to suggest a change and permission to execute it are separate decisions.

The first raises questions about engineering access and code quality. The second also needs authority defined for each business action. OWASP’s guidance on excessive agency identifies excessive functionality, permissions and autonomy as risks. Its recommendations include narrow tools, downstream authorization and human approval for high-impact actions.

A team can use both approaches effectively when it makes those responsibilities explicit.

Autonomy is a dial, not a switch

Teams tend to argue about whether a system should be autonomous. The productive question is how far along a ladder each action belongs.

• Read and recommend. Present an issue with evidence while leaving the record unchanged.
• Prepare for approval. Stage specific values for an authorized person to review.
• Execute an approved action. Apply the reviewed change only while its authorization and underlying data remain valid.
• Operate within an approved policy. Automate a bounded class of actions with enforced limits, monitoring and exception handling.

The appropriate level depends on consequence, reversibility and evidence. A reminder can have a different approval path from a change to a customer’s contracted price. Establish that distinction before granting tools broad access.

The P21 price change: a hypothetical worth walking through

Consider a hypothetical distributor reviewing a supplier price change in Epicor Prophet 21.

The supplier announces a cost increase for next month. The team needs to assess which open quotes would lose margin if fulfilled at that future cost. Some customers have protected pricing. Branches may use different pack quantities. Effective dates, units and customer agreements all affect the decision.

The opportunity is to assemble that review with less manual handling, while preserving the pricing team’s authority over any proposed changes.

There is already functionality to investigate before commissioning an extension. Epicor’s March 2026 automation overview describes Prophet 21 business rules, including DynaChange and Web Visual Rules, pricing and margin validation, notifications, user-defined tables, APIs and native AI capabilities. Discovery must establish the actual release, hosting arrangement, licenses, configuration and supported interfaces. Custom work should address the remaining requirement.

If the remaining need is a cross-system pricing review, the extension could work as follows:

• Use AI to interpret the source. Extract proposed costs, units and effective dates from the supplier’s document. Keep the source reference and flag ambiguous values. Obtain affected ERP records through authorized, defined read tools.
• Use explicit rules for the calculations. Code validates item matching, pack conversion, agreement exceptions and margin scenarios, then ranks the review queue. AI can explain the result without being the authority for the arithmetic.
• Approve a specific proposal. Show the reviewer the original values, proposed changes and source evidence. Record who approved that version, within which branch and pricing authority.
• Verify the posting boundary. Use an available, approved integration or extension mechanism rather than writing directly to core ERP tables. Confirm which validation and business rules that path actually applies.
• Protect against stale decisions. Check critical values as part of a concurrency-safe posting operation. If they changed, reopen the review. If the interface cannot prevent an unsafe stale write, keep automatic posting disabled until a supported control is established.
• Resolve uncertain outcomes. Track a stable operation reference and reconcile with the ERP before retrying an ambiguous submission. If the interface cannot establish whether it already posted, route it for resolution rather than risking a duplicate.

Microsoft’s retry guidance describes the underlying failure: a service can process a request but fail to deliver its response. Repeating a non-idempotent action can then perform it twice. An extension’s operation identifier alone cannot make an external endpoint safe; duplicate protection must cover the actual business action.

The integration must distinguish submission, acceptance and the confirmed business result. Response codes and returned records need interpretation against the interface contract. No design should assume every P21 endpoint exposes every field, runs every rule or offers a conditional-update feature. Those are implementation questions to verify in the customer’s environment.

Begin with representative test transactions and read-only comparison against the team’s established decisions. Then consider a limited branch rollout with agreed health checks, controlled request volume and a manual fallback. Microsoft’s safe-deployment guidance supports progressive exposure, health gates and stopping a harmful rollout before expanding it.

The rollout should protect ordinary order entry, purchasing and fulfillment as well as the new workflow. Test response times and concurrent activity under representative load. Define when to pause the extension and who can do so. Turning off new processing does not undo changes already posted: recovery also needs reconciliation and an approved correction path. Operational continuity is an acceptance requirement to validate, rather than an unconditional promise.

Security belongs in the design and the operating controls

Security decisions belong outside the prompt.

A development agent should work with deliberately scoped tools and isolated environments. It does not need unrestricted authority over live databases to help build an application. Production changes require a controlled release path, appropriate access and a record of what was deployed.

The same discipline applies inside delivered workflows. Access should be scoped by tenant, by branch, by role. A document a customer uploaded is data to be interpreted, not an authority to be obeyed — an instruction sitting inside a PDF is content, not permission.

NIST’s Secure Software Development Framework, published in 2022, recommends integrating security practices into the development life cycle to reduce vulnerabilities and address their causes. The relevant lesson is practical: security needs requirements, implementation and validation throughout the work, rather than a final check after the feature is built.

Concurrency and the record

The hardest defects here are not wrong answers. They are right answers applied to the wrong state.

Two people review the same quote. One approves. The other's screen still shows the old cost. Meanwhile a third process updates the price file. The approval was well-intentioned and no longer describes reality.

Microsoft’s compensating-transaction pattern addresses recovery across multiple systems. A correction may need business-specific actions that respect work completed since the original request. Restoring an old snapshot can overwrite valid concurrent changes. Reverting code also cannot retract a message already delivered to a customer.

Which makes the design questions concrete. What is the unit of work? What is the stable identifier? What happens on partial failure? Who is accountable for the correction?

Scope is a business decision

A small first release can be the right investment. It still needs boundaries that account for the likely users, data and next steps.

A read-only report and a write-back integration carry different responsibilities. So do a single-branch review and an employee portal used across a company. If scope changes, revisit permissions, transaction ownership, expected load and recovery needs alongside the feature estimate.

A useful discipline is to state the bounded outcome before the first line of code: which records change, who can trigger it, what limit applies, and what the fallback is. Everything outside that sentence is a separate conversation with its own decision.

The same discipline beyond distribution

The opportunity extends across industries. These are additional proposed use cases:

Construction cost and change reviews. An application could connect supplier quotations, current job costs and proposed changes, highlight discrepancies and prepare a review package. Project permissions, dated source costs and approval limits keep one job’s information and commitments within the right boundaries.

Warehouse exceptions. In a HighJump or Körber-branded environment, an extension could gather discrepancy evidence and route a short pick to the right supervisor. Physical stock confirmation, allocation rules and a reconciled ERP handoff still govern the outcome. Infios describes the HighJump/Körber software lineage and its 2025 rebranding; the actual installed product and version remain important integration facts.

Commissions and employee portals. A controlled application could explain a commission using its source transactions, effective rules and authorized adjustments, then give employees access to their own results. Payroll review and private access need clear boundaries; an explanatory AI response should not silently change the approved calculation.

Specify what done means

Acceptance criteria are where most of the value is either locked in or quietly lost.

For a workflow like the one above, "it works" is not a criterion. Useful ones look like this: the ranking matches human review on a defined sample; a stale approval is rejected; a duplicate submission produces exactly one posted change; the audit record reproduces the reviewer's decision; the fallback path has been exercised and documented.

Maintainability deserves the same treatment. Who owns the rules table? Can a threshold change without a deployment? Is there a written recovery and data-repair path for the morning a release misbehaves on a shipping day?

What an experienced partner actually contributes

Most of the difficulty in this work is not novel. It is the accumulated detail of how distribution, manufacturing and construction businesses actually operate — the pack conversions, the branch differences, the contract exceptions, the commission splits that no generic template anticipates.

JWilliams & Associates combines decades of hands-on systems experience with modern agentic development and custom application engineering. Its public service background includes HighJump, Prophet 21, SQL performance work and applications connecting operations to finance. The value of that experience is the operational context brought to discovery: the transactions, exceptions and dependencies that a feature request may leave unstated.

The firm’s AI agent services describe defined tools, permissions, evaluation and review of consequential actions. Its engineering and security policy makes discovery, authorization, controlled data access and release validation explicit expectations. That gives a customer concrete subjects to examine in a proposed engagement.

JWA’s contribution should be visible in the project: clear scope, explained tradeoffs, tested transaction behavior and an operating handoff the next person can support. The starting point is the customer’s problem, whether the answer is configuration, an extension, an integration or a new application.

Questions worth asking before the next build

• What record does this change, and who is entitled to rely on it?
• Which parts are arithmetic and which are judgment? Are they separated?
• What happens if the same request arrives twice?
• What makes an approval stale — and does the software notice?
• What can this system touch, and is that enforced outside the prompt?
• What is the manual fallback, and has anyone actually run it?
• Who owns the rules after launch?

Where this leaves the business

The opportunity is substantial: give people clearer information, remove repeated handling and help them act sooner on exceptions that matter. Experienced engineering and modern AI tools can work together toward that outcome.

The confidence to expand comes from evidence that the system preserves the right permissions, produces the intended records and behaves predictably when something goes wrong. Build that evidence into the project, and intelligent software becomes a capability the business can evaluate and improve.

The strongest first step is a useful workflow with a clear owner and a result the team can verify. That is where an ambitious AI idea starts becoming dependable business software.