Systems Foundations for Agentic AI

TL;DR

• The hard part is the cross-cutting concerns. A customer-service agent handling returns touches knowledge bases, inventory, ERP, payments, escalations, and email. Making that reliable means retries everywhere, queuing for load, and state management — and conventionally that systems logic gets interleaved with the business logic.
• Durable execution is Temporal's answer: put systems logic on one side and application concerns on the other, write ordinary code in ordinary languages, and get crash-proof execution. After a crash there are only two ways to recover state — save it or recompute it — and Temporal gives you simple annotations to say which. "If there's a trick, that's the trick."
• Three properties of agentic workloads: non-determinism (validate and store LLM responses — though the flip side is they're forgiving about inputs); security (beyond prompt injection and alignment, a great threat model is plain bad judgment — it happens that rm -rf); and execution profile (you're touching the world, so write state down carefully; load is bursty, which calls for serverless).
• A spectrum of agency: level 1 is regular code driving control flow with LLMs at specific points (great and very reliable for things like summarization); level 3 is the agentic loop where the LLM decides what happens next; the far end is self-evolving agents. More agency isn't always better — good abstractions let you move along the spectrum without rewriting the application.
• Announced on stage: the Temporal Agent Harness — not yet a supported product, so go star the repo. Abstractions on top of durable execution, with a pluggable inner harness (OpenCode, OpenAI Agents SDK, Pydantic AI), pluggable tools, and pluggable interfaces (Slack, Teams), plus observability into what the agent reasoned about at each step.

Key Points

The functionality isn't the hard part (~00:50–00:52)

A system is functionality assembled out of a pile of components, and AI has a lot of components. But beyond the core functionality there are cross-cutting concerns: reliability (Temporal's deep specialty), efficiency, security, and evolvability — which covers scalability, upgrades, and the rest.

He used reliability as the way in, because it explains Temporal's core mechanism. Take a customer service agent handling returns: it needs knowledge bases, inventory, ERP, payment handling, probably escalations, and the ability to send email. To make that work reliably you need retries in a whole bunch of places, probably queuing to handle load, and state management to track the process all the way through. Every one of those is a place things go sideways, and whoever builds it has to account for them.

The underlying problem: traditional software interleaves application concerns — the business logic — with systems concerns.

Durable execution: pulling the two apart (~00:52–00:53)

If there's one takeaway about what Temporal makes possible, it's the model of durable execution: it lets you write code that puts systems logic on one side and application concerns on the other, genuinely isolated.

The Temporal open source project lets you build crash-proof applications — MIT licensed, backed by databases like Postgres or Cassandra, with a cloud product alongside. The key point is that you write regular code in regular programming languages (Python, TypeScript, you name it) and get crash-proof execution.

How do you recover after a crash? There are only two ways to get the state back: save it or recompute it. Temporal gives you simple annotations to put on your code saying "recompute this here, save state there." As he put it: "if there's a trick, that's the trick." There's other neat material too, like getting distributed systems out of ordinary language primitives.

Who's using it (~00:53–00:54)

He cited the VP of application infrastructure at OpenAI. The notable application is ChatGPT Images, where a whole series of steps have to happen reliably to produce the image; Codex on the web is another. Beyond that it spans infrastructure control planes, data connectors (effectively building and maintaining RAG indexes), and traditional business processes. Across the ecosystem: Nvidia, Cursor, SpaceX, Lovable, Replit.

What makes agentic workloads different (~00:54–00:56)

His AI Foundations team spends its time on what the right abstractions are for agentic AI workloads, what the tradeoffs are, how to slice them, where to pick a point in the space and where to expose a knob instead. He stressed this is genuinely a different workload from anything systems people have had to handle before, which makes rethinking the abstractions fun. Some observations:

• Non-determinism. Calling into an LLM means you need to validate and store those responses. But there's an interesting flip side: it's fuzzy, and therefore forgiving with respect to its inputs.
• Security. The usual threat framing is adversarial input — prompt injection, alignment. But a great threat model for agents is just bad judgment: "it happens that rm -rf," by accident rather than intent. That drives a lot of their design considerations.
• Execution profile. You're interacting with the world, which is exactly where you want to capture state and write things down carefully. And load is bursty, which calls for serverless and the like.

The spectrum of agency: more isn't better (~00:56–00:57)

Another observation from working across the ecosystem: there is a spectrum of agency, and the right solution for a given piece of functionality can come from anywhere on it — and more agency is not always better.

• What people usually picture is level 3: an agentic loop where the LLM makes all the decisions about what happens next.
• To the left, at level 1, there's a huge number of applications — summarization among them — where the job gets done very well by having regular code drive the control flow with LLMs inserted at very specific points. That can be very reliable, and if it gets the job done it's probably the right solution.
• At the far end are self-evolving agents, which now show up in some harnesses. There's a reason for them, but they're probably not the right solution for most jobs either.

Temporal's abstractions for agentic AI are designed to let you dial that in, and move back and forth along the spectrum without rewriting your entire application.

Announced: the Temporal Agent Harness (~00:57–00:59)

The thing he shared on stage: the Temporal Agent Harness. Not yet a supported product — "if you go and star the GitHub repo, then hopefully it will be soon."

It's a set of abstractions built on Temporal's core durable execution primitives, designed for mix-and-match:

• A pluggable inner harness — a coding agent like OpenCode, or OpenAI Agents SDK (which he noted has interesting sandboxing functionality), or Pydantic AI. They've worked hard to embrace the ecosystem.
• Pluggable tools.
• Pluggable interfaces — talk to it through Slack, Teams, whatever.

His screen grab showed an OpenCode session fixing a bug in a simple program. Because it ran under the agent harness, he got not only durability and reliability (which matter when you want to run at scale) but also, effectively for free, observability: the ability to dive in and see what the agent was reasoning about at each step, what the tool calls were, and what human approvals happened along the way. That, he argued, is the payoff for being thoughtful about the abstractions you bring into agentic AI.

Quotes

"There's basically two ways to get that state back. You can either save it or you can recompute it. … And that's sort of, if there's a trick, that's the trick." (~00:53)

The whole secret of durable execution.

"A great threat model when you're thinking about agents is actually just bad judgment — because it happens that rm -rf." (~00:55)

The more common source of disasters than prompt injection.

"The more agency you have, it's not always a better thing." (~00:56)

Counterintuitive but practical: if plain code does the job reliably, don't force an agentic loop onto it.