Engineering
The backend still matters when the interface is AI
Why approval, state and recovery deserve as much attention as the model response.
A response is only one part of the system
My professional software background is in enterprise financial-services systems. At SunTec, I worked on Java and Spring Boot services, data-processing workflows, SQL optimization and releases. My AI work now includes retrieval, training and local agent applications. These are different kinds of experience, but they share a practical concern: what happens after an input reaches the system?
A language model can propose an action or explain a plan. The application still needs to decide whether that proposal is current, permitted and complete enough to execute. It needs to handle duplicate requests, partial responses, changing data and failures between steps. A fluent sentence does not settle any of those questions.
Keep proposal and permission separate
OwnStack makes this distinction explicit. A model interpretation is a proposal. The host retains authorization and checks tenant, project, scope, expiry and revocation. Exact human approval belongs to a particular change, rather than to any future action that happens to sound similar.
The local implementation also preserves failed model patch attempts. A passing manual recovery fixture is useful engineering evidence, but it is not a successful model-generated patch. Keeping those outcomes separate makes the system easier to understand and prevents the interface from telling a more impressive story than the execution record.
Use states that mean something
In IntentCart, a feasible basket, a minimum-cost basket within a finite catalog, an approved quote and a completed payment are separate claims. A price change can invalidate approval even if the items still fit together. A simulated recovery result cannot stand in for a real provider receipt.
Relief Atlas applies a similar idea to everyday coordination. Outreach queued, helper accepted, helper reported completion and organizer confirmed completion mean different things. If a helper declines, the task is uncovered. A new recovery plan needs review; a hopeful animation should not silently turn it into completed help.
Build the failure path into the product
This is where backend work becomes visible in an AI product. Idempotency, durable records, stale-result checks and explicit unknown states give the interface something truthful to show when events arrive out of order or a process stops. Tests should challenge those boundaries, not just confirm the happy path.
It also changes the design of a demo. Show the review step, the rejected stale request and the unresolved state. Those moments explain who has authority and what the software knows. They are part of the product experience, not merely backend implementation details.
These projects remain local prototypes with fictional or synthetic scenarios. Their tests do not establish production AI experience or real customer outcomes. They do show the engineering questions I choose to make concrete. A useful next step is always specific: verify a missing effect, test a recovery boundary or measure the actual user journey, rather than treating a more elaborate model response as proof that the system works.