Why Your Enterprise Tech Stack Isn't Ready for AI Agents - And What to Build Instead

What does it take to turn a successful healthcare AI proof of concept into a system an enterprise can actually deploy? Healthcare makes that question particularly demanding: process, compliance and regulatory requirements sit alongside decisions with direct consequences for patients. Christopher Lovejoy introduces himself as an Anthropic forward-deployed engineer who embeds with enterprises, having previously worked at Anterior with Saul Howard. Howard introduces himself as Anterior’s VP of engineering, building agentic AI for US health insurers. Their experience has implications for finance, defense and government—other environments where following the process is part of getting the answer right.

Consider their hypothetical large health system with an administrative workflow to automate. The customer and engineering team agree on the use case and the metrics that will define success. In the hypothetical POC, two engineers spend four weeks building the application. The agent needs model-provider access and data spread across the application layer, control plane and data plane. Some inputs come from a data lake; others come directly from applications, through a mixture of offline pulls and online connections. The prototype connects wherever it needs to connect to produce a result.

The POC meets its unspecified performance targets, runs quickly and looks relatively inexpensive. Finance starts asking about next year’s budget. Medical leadership wants to tell colleagues about the accuracy. Sales wants to put an AI badge on the website. Everyone is acting as though the difficult work is finished because the model performed well. The production review is where that assumption breaks down.

At the next meeting, the deployment requirements become concrete:

• Auditability: Can compliance inspect every action and every piece of data the agent accessed? The prototype’s incomplete integrations make that difficult.
• Data boundaries: How does sensitive information reach the agent, and does that path respect restrictions on where it may travel?
• Clinical approval: Which decisions require a clinician, and what mechanism lets that clinician approve or disagree?
• Security and continued performance: Can untrusted inputs manipulate the model, and how will the team know whether it keeps performing well?
• Application integration: How will the system connect to Epic, Salesforce and other operational applications?

The architecture developed here concentrates on audit trails, data handling, escalation and evaluations. Data isolation also provides a place to address prompt-injection risk; application integration remains a separate engineering problem.

An audit trail can sound like an ordinary developer log in Datadog. Howard sets a stronger architectural target for work subject to frameworks and regulations such as SOC 2, HITRUST and HIPAA: record every action, every data access and the authorization under which each action occurred. His test is whether the team could reconstruct a justifiable chain of evidence if an agent’s decision were challenged in court. That is a design standard, not a claim that these regimes prescribe event sourcing or that a storage choice guarantees admissible evidence.

The design question becomes: What must the system make easy? If historical reconstruction is essential, use a transaction log of the kind familiar in finance. The log is immutable, append-only and timestamped. It captures the system’s events comprehensively and provides one source of truth, including when multiple agents run in parallel. Agent history is then the primary record from which state is derived, rather than a secondary stream of debugging messages.

With this event sourcing pattern, an audit view reconstructs the recorded state at a chosen point in history. The storage decision makes historical inspection straightforward, but shifts complexity into reads.

Caches and snapshots reduce reconstruction work without removing the need to design it. That flexibility is useful in healthcare: later events can change how a patient’s journey should be interpreted. The raw record remains intact while the views over it remain computed, replaceable projections.

The next question concerns the lifecycle of protected health information, or PHI. Howard’s design goal is to give humans and agents only the data needed for the particular task and patient journey. That operational constraint should not be confused with a universal statement about HIPAA: its minimum-necessary standard has exceptions, including disclosures to or requests by providers for treatment. The architecture still needs an explicit place to enforce the applicable access rules.

The shape of the data matters. Healthcare records combine structured and unstructured material, with relationships that do not fit a simple hierarchy. Howard notes that an individual healthcare-data item can exceed one megabyte. Role-based access control applies to humans and the agents acting downstream of them. Some customers also require the data to remain inside their own environment or VPC. Schema-driven object storage fits these requirements by giving the payload its own storage and access boundary.

Events describe what happened; immutable objects preserve the data used. An event contains a reference to a schema-driven blob, rather than embedding the healthcare payload. The object must remain immutable so that a historical reference still identifies the exact data available to the agent at that moment. Separating the two also separates operational visibility from permission to read PHI: a developer can follow the sequence of actions and inspect the shape of the referenced data without receiving the underlying patient information. Observability, orchestration and instrumentation no longer require copying sensitive payloads throughout the system.

Object access then becomes an enforcement point for zero trust. An agent presents a token when it needs a particular object, instead of acquiring sensitive information merely because that information is flowing through the orchestration machinery. Howard connects this separation to mitigation of the lethal trifecta: private-data access, exposure to untrusted content and external communication. His architectural question is whether an agent allowed to access data at one point can also reach another prohibited source. Segregating object storage from the event stream gives the system a place to restrict that combination of access. The proposed same-process exclusion depends on actual token policies and isolation; storage separation alone is not a complete prompt-injection defense.

Human approval is difficult to place on a fixed workflow diagram because the need for it may emerge during execution. An agent might escalate when uncertain, or a rule might require approval when a treatment exceeds a threshold. Context creates a second difficulty: a large volume of text may be a convenient model input but a poor interface for a clinician who needs to make a decision.

Lovejoy’s proposed abstraction is to define an agent broadly enough to include both an LLM and a human. Any action available to the LLM must also be performable by a person. At an escalation point, the human completes that action, and downstream steps consume the same result contract regardless of who produced it. Actor identity can remain part of the audit record without forcing every downstream step to implement a separate human workflow.

Shared context supports that equivalence without requiring identical interfaces. One representation can become a prompt for the LLM and a UI for the human. For example, an illustrative TypeScript contract can keep a treatment review pending until either kind of actor completes it:

type ReviewContext = Readonly<{
  reviewId: string;
  evidenceRefs: readonly string[];
  approvalReason: string;
}>;

type ReviewResult = Readonly<{
  reviewId: string;
  decision: "approve" | "decline";
  rationale: string;
  actor: { kind: "human" | "llm"; id: string };
}>;

interface Reviewer {
  review(context: ReviewContext): Promise<ReviewResult>;
}

function reviewPrompt(context: ReviewContext): string {
  return [
    `Review: ${context.reviewId}`,
    `Approval required because: ${context.approvalReason}`,
    `Evidence references: ${context.evidenceRefs.join(", ")}`,
    "Return a decision and rationale after reviewing authorized evidence."
  ].join("\n");
}

function reviewUi(context: ReviewContext) {
  return {
    title: `Review ${context.reviewId}`,
    reason: context.approvalReason,
    evidenceRefs: context.evidenceRefs,
    choices: ["approve", "decline"] as const
  };
}

async function completeReview(
  context: ReviewContext,
  reviewer: Reviewer
): Promise<ReviewResult> {
  return reviewer.review(context);
}

The selected Reviewer supplies the decision; rendering a prompt or a UI does not itself approve anything. Both presentations preserve the same task identity and evidence references, while adapting the context to the actor who must use it.

Evaluations guide model selection and product design, but their inputs and comparisons are difficult to stabilize. LLM nondeterminism complicates attribution: a changed output does not necessarily identify the change that caused it. An offline sample may fail to represent production in the first place, and data drift can make a once-useful dataset stale.

The preceding primitives provide the ingredients for evaluations within the architecture:

1. Reconstruct the case. Use the immutable ledger to recover recorded state at a chosen point, then vary a prompt, model or piece of code. This holds the historical context available for comparison. Safe reruns also need preserved external responses and controls against repeating external side effects; reconstructing state is not the same as safely executing the workflow again. Lovejoy describes targeted replay as revealing the impact of a change, though the comparison still has to account for model nondeterminism.
2. Compare actors on the same task. Because a human and an LLM share the action contract, both can perform the task on the same inputs. Their difference becomes an evaluation signal. Turning that difference into a score requires a task-specific scoring rule; the talk supplies no formula.
3. Keep production payloads inside the customer boundary. Lovejoy describes running evaluations on production data within the customer’s environment and returning results without exporting sensitive payloads to the external agent-work location. The execution placement must support that boundary; object references alone do not establish it.

Together, replay, interchangeable actors and isolated payload storage make evaluation a capability of the system rather than a separate collection of copied cases.

The immutable action ledger, object storage beside the orchestration layer and human–agent equivalence reinforce each other. Together they make evaluation a first-class property of the system. The broader architectural choice is deliberate: simplify the operations that matter most, accepting that other operations—such as reading state from an event history—will require more work. Established patterns from finance, defense and large technology systems offer useful foundations, even when agent systems require new combinations of them.

Howard’s observed failure mode is to keep the successful POC as the foundation and attach security, auditability and evaluations whenever a new requirement appears. The result becomes brittle and difficult to generalize across use cases. His preferred path reverses that sequence: take the constraints of a scaled enterprise system seriously at the beginning, build the primitives around them, and then work back toward the POC’s accuracy. Production requirements determine the foundation; model performance is what the team builds on top of it.