Thoughts on Long-Horizon Agents

Some background so you know where this is coming from: I was a director of engineering at a SaaS company that got to unicorn scale. One of the domains my tribe owned was self-service onboarding. For the last 14 months, 4 of my squads have been rebuilding that experience as agentic flows, trying to replicate some of the experience of a sales-assisted journey. With better models and agent harnesses, I have seen huge improvements in what agents can do. But onboarding is a long game. Many customers need assistance for 90+ days. You need to remember what they are trying to achieve, their preferences, what has happened and when to step in again. Long horizon agents look a lot like workflows, but not in the traditional rigid sense. Take onboarding. There is an overall goal, broken into smaller tasks. Some have dependencies, others are completely independent. Instead of a single connected DAG like Airflow, Zapier or n8n, you end up with something closer to a disconnected graph of possible tasks. And a task is not an action. It is a scoped goal. An agent is attached to it and can take multiple actions, make decisions and adapt until the goal is complete. This abstraction has been useful because it makes two important things deterministic: What is the best next task to take on? How do we evaluate whether a task is actually complete? The agent handles the non-deterministic part, figuring out how to achieve the goal. But the system doesn't have to trust it to decide what to work on next or simply self-report that the work is done. This matters because false task completion is one of the biggest problems I have seen in enterprise agent deployments and adding a supervisor agent doesn't reliably solve it. The same principle applies to infrastructure. Say a user uploads files that need to be verified. You could pass file IDs and names through LLM and let it call the verification tool. But now the model can truncate, modify or hallucinate those identifiers. Instead, build an attachment inbox that processes and stores files before LLM ever sees them. So LLM decides what should happen. Deterministic infrastructure handles how the data moves. That eliminates an entire class of hallucinations. This is where I think the biggest investment needs to go: zero-token architecture. Build high-quality tools and minimize the parameters they require from LLM. Because task definitions are declarative, with dependencies and success criteria defined explicitly, I was also able to build a compiler around them. That gives me two useful properties: I can test workflows almost instantly, more like unit tests than manually executing an entire process. LLM can generate or regenerate workflows from existing information, then compile and verify them against deterministic rules. So LLM doesn't invent a workflow and hope it works. It generates a definition, the system verifies it and can fix it if something is wrong. I surely haven't covered many other aspects of long horizon agents here, like memory layers, runtime generation of an agent for each task and plenty more. I'll probably write about some of those later. For now, this was mostly an attempt to sharpen my own thinking and I find that writing usually helps. Hope it was useful for some of you too.