Designing AI Systems That Fail Honestly
The most dangerous AI systems do not crash. They keep responding while their evidence is stale, policies conflict, retries multiply, tool calls become expensive, or the system can no longer justify the commitments it is making.
In this hands-on workshop, participants redesign a failing AI-commerce workflow that appears technically healthy but is behaviorally unsafe. They work through conflicting inventory information, an ambiguous payment timeout, a stale return policy, and an exhausted AI tool-call budget. The objective is to design a system that remains useful without making promises it cannot defend.
Traditional reliability asks whether a service is up, fast, and error-free. AI systems introduce a higher bar: whether the system is still safe to trust. A dashboard can be green while customers receive incorrect answers, duplicate actions, unfair denials, or decisions nobody can explain later.
This workshop gives teams an architecture method for controlling that risk. Instead of treating the system as simply “working” or “down,” participants design modes that progressively reduce autonomy: answer normally, become conservative, defer the decision, freeze liability actions, or escalate to human review.
Session details:
Participants work in teams on a realistic commerce-agent scenario. The agent can answer customers, check inventory, interpret return policy, initiate refunds, and call external tools. Then the workshop injects failures:
Inventory data is eight minutes stale.
A payment call times out after the customer may already have been charged.
A retired return policy outranks the current policy.
Retries create duplicate side-effect risk.
The tool-call and cost budget is nearly exhausted.
APIs return successful responses, but the evidence is no longer reliable enough for a customer commitment.
For each failure, teams answer:
What promise has the business made to the customer?
What can the AI still safely show or say?
What evidence is admissible for this decision?
What must the system stop doing?
When should it defer, refuse, or escalate?
What proof is needed before automation can be re-enabled?
Participants use an architecture canvas to make the hidden controls explicit: customer promise, commitment boundary, admissible evidence, freshness rules, churn budgets, degraded modes, human-review triggers, and decision receipts.
About Rohit Bhardwaj
Rohit Bhardwaj is a Director of Architecture working at Salesforce. Rohit has extensive experience architecting multi-tenant cloud-native solutions in Resilient Microservices Service-Oriented architectures using AWS Stack. In addition, Rohit has a proven ability in designing solutions and executing and delivering transformational programs that reduce costs and increase efficiencies.
As a trusted advisor, leader, and collaborator, Rohit applies problem resolution, analytical, and operational skills to all initiatives and develops strategic requirements and solution analysis through all stages of the project life cycle and product readiness to execution.
Rohit excels in designing scalable cloud microservice architectures using Spring Boot and Netflix OSS technologies using AWS and Google clouds. As a Security Ninja, Rohit looks for ways to resolve application security vulnerabilities using ethical hacking and threat modeling. Rohit is excited about architecting cloud technologies using Dockers, REDIS, NGINX, RightScale, RabbitMQ, Apigee, Azul Zing, Actuate BIRT reporting, Chef, Splunk, Rest-Assured, SoapUI, Dynatrace, and EnterpriseDB. In addition, Rohit has developed lambda architecture solutions using Apache Spark, Cassandra, and Camel for real-time analytics and integration projects.
Rohit has done MBA from Babson College in Corporate Entrepreneurship, Masters in Computer Science from Boston University and Harvard University. Rohit is a regular speaker at No Fluff Just Stuff, UberConf, RichWeb, GIDS, and other international conferences.
Rohit loves to connect on http://www.productivecloudinnovation.com.
http://linkedin.com/in/rohit-bhardwaj-cloud or using Twitter at rbhardwaj1.