# Why Your Enterprise Tech Stack Isn't Ready for AI Agents Christopher Lovejoy, Anthropic & Saul Howard, Anterior | AI Engineer World's Fair 2026 | 19:15 Source: https://www.youtube.com/watch?v=mav15aW9lLM Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/why-your-enterprise-tech-stack-isnt-ready-for-ai-agents Published: 2026-08-19 Tags: enterprise, evals, human-in-the-loop, security ## TL;DR - A successful healthcare proof of concept still fails if it cannot answer questions about auditability, data access, escalation, and evaluation. - An immutable event log, separate immutable object storage, and shared human-model agent actions make several enterprise requirements easier to enforce. - Production systems should start with their regulatory and operational constraints, then build back toward the proof-of-concept accuracy. ## Summary Christopher Lovejoy and Saul Howard describe the gap between an impressive enterprise AI proof of concept and a system that can enter production. Their healthcare examples involve strict controls over process, protected health information, authorization, and clinical approval. A developer log does not provide the complete evidence trail that security and compliance teams need. They propose an immutable append-only event log as the system's source of truth, with healthcare data stored separately in schema-driven immutable object storage and referenced by events. This separation supports controlled data access and lets developers inspect an agent's actions without receiving the underlying patient data. Treating humans and language models as the same kind of agent makes escalation dynamic. Evaluation can then use replayed events, human comparisons, and production data inside a customer environment. Their advice is to design around production constraints from the start instead of attaching enterprise controls to a finished demo. ## Key ideas ### Healthcare exposes enterprise constraints that also apply to other regulated industries [00:01](https://www.youtube.com/watch?v=mav15aW9lLM&t=1s) Lovejoy and Howard begin with healthcare because it combines strict process and compliance requirements with direct effects on people's lives. Saul Howard describes Anterior as a company selling agentic AI to US health insurance companies. They argue that the lessons transfer to finance, defense, government work, and other settings where processes must be followed. The problem is therefore broader than healthcare integration. Teams building agents for regulated enterprises need to design around the consequences of the work, the rules governing data, and the required approvals before they assume that a working model is close to deployment. ### A proof of concept can meet its metrics while avoiding the real production questions [01:57](https://www.youtube.com/watch?v=mav15aW9lLM&t=117s) The example starts with a large health system and an administrative healthcare workflow. The team scopes a proof of concept, defines benchmark metrics, assigns engineers, and spends four weeks building it. The application connects across an enterprise stack, including an application layer, a control plane, a data plane, model-provider access, and data from places such as a data lake. The result is fast, relatively cheap, and accurate enough to satisfy the initial meeting. Finance wants to understand the budget impact, the chief medical officer wants to discuss accuracy, and sales wants to put "powered by AI" on the website. ### The hard part begins when stakeholders ask how the system will operate [03:39](https://www.youtube.com/watch?v=mav15aW9lLM&t=219s) The team initially assumes that the AI was the difficult part. At the productionization meeting, compliance asks for an audit trail showing every action the agent took and every piece of data it accessed. Other questions follow: how sensitive data moves through the system, whether it crosses forbidden boundaries, who approves decisions that require a clinician, and whether untrusted data can manipulate the model. The enterprise also needs integrations with systems such as Epic and Salesforce. Lovejoy and Howard focus on audit trails, sensitive data, escalation, and evaluation because these expose the architectural gaps in the proof of concept. ### An audit trail must provide a complete chain of evidence [05:19](https://www.youtube.com/watch?v=mav15aW9lLM&t=319s) Howard distinguishes an enterprise audit trail from a developer log in a tool such as Datadog. Under frameworks including SOC 2, HITRUST, and HIPAA, the record must contain every action taken by the agent, every place where it accessed data, and the authorization behind each action. He frames the requirement legally: if an agent's decision reached a court, could the organization show a justifiable chain of evidence for the actions that produced it? That requirement changes the storage design. An audit trail is a record of the system's actions and permissions, rather than a convenient stream of debugging messages. ### An immutable append-only event log makes historical reconstruction easy [07:03](https://www.youtube.com/watch?v=mav15aW9lLM&t=423s) The proposed transaction-log pattern stores an immutable, timestamped, append-only record of events. It is complete and unified, giving parallel agents one source of truth. Auditability then follows from the storage model because the team can reconstruct the state of the system at a particular point in time. The tradeoff is that writes are easy while reads become harder, since a current view must be reconstructed from events. Caches and snapshots can help. Howard also points out that healthcare teams may need new interpretations of the raw history later, and ephemeral projections make it possible to create different views without changing the source log. ### Sensitive healthcare data belongs beside the event log, with events holding references [08:46](https://www.youtube.com/watch?v=mav15aW9lLM&t=526s) Healthcare data can be structured or unstructured, large, and subject to strict access controls. Some customers will not allow it to leave their own environment or on-premises virtual private cloud. Howard recommends schema-driven object storage for the data and a separate event log for what the agent did. Events contain references to immutable data objects rather than the healthcare data itself. Because both the event and the referenced data remain immutable, the system can reconstruct what data the agent could access at a given time. Developers can inspect the data's shape and retrace the agent's steps without being granted access to protected health information. ### Zero-trust access limits where an agent can use data [12:15](https://www.youtube.com/watch?v=mav15aW9lLM&t=735s) Separating orchestration events from healthcare objects creates a place to enforce zero-trust principles. Agents carry tokens and use them to access data at the point of use, instead of allowing data to flow freely through the system. Howard connects this design to prompt-injection risks and the "lethal trifecta." The architectural question is whether an agent that has access to data at one point can also reach another sensitive source within the same process. Token-based access and segregated object storage give the system a way to enforce that constraint. The design does not treat access as an incidental property of the prompt or application process. ### Treating humans and models as agents makes escalation independent of the actor [13:07](https://www.youtube.com/watch?v=mav15aW9lLM&t=787s) Escalation is difficult because the system may not know in advance when it will be needed. A language model might escalate when it is uncertain, while a rule might require approval for a treatment above a threshold. Humans and language models also handle context differently. The proposed solution is to define an agent broadly enough to include both. Any action available to a model is also available to a human, so a human can take over at any point and downstream steps do not need to know who acted upstream. Shared context can then be rendered as a prompt for a model or as a user interface for a person. ### Evaluation can emerge from the architecture instead of being added afterward [14:49](https://www.youtube.com/watch?v=mav15aW9lLM&t=889s) The speakers describe several evaluation problems: language models are nondeterministic, offline samples may not represent production data, and data can drift over time. Their three architectural primitives address these problems. The immutable ledger allows the team to replay a sequence from a particular point, change a prompt, model, or piece of code, and observe the direct effect. Human-agent equivalence lets both a person and a model perform the same task, with their difference providing an evaluation signal. Object storage allows evaluations to run on production data inside the customer's environment without exposing the sensitive data to the team running the agent. ## Notable quotes - "An audit trail is a bit more than that. It has to contain a complete record of absolutely every action that the agent took." (05:35) - "Auditability becomes trivial. It falls out of your data storage paradigm that you've chosen." (07:23) - "You can separate out observability and orchestration and instrumentation from the healthcare data itself." (11:31) - "Any action that can be taken by an LLM could also be taken by a human." (13:55) - "Where I've seen it go wrong is taking that initial point solution that showed so much promise and then trying to build up from it." (17:48) ## Tools & references mentioned - Anthropic - Anterior - Datadog - SOC 2 - HITRUST - HIPAA - Epic - Salesforce ## Who should watch - You are taking an agent proof of concept into a healthcare, financial, defense, or government organization and expect compliance questions after the demo. - Your system needs human approval, protected data access, or an audit trail that could support an investigation or legal review. - You want evaluations on customer production data but cannot move that data into the environment where the agent is developed.