The current conversation about AI agents often focuses on larger context windows, better retrieval, more capable models, improved agent harnesses, and increasingly sophisticated execution graphs. All of these advances are useful. They are helping us understand how probabilistic models can be turned into systems that perform increasingly complex work. But they may still be optimizing the wrong abstraction.
At LatentSpin, we believe two fundamental limitations stand between today's agents and genuinely autonomous systems for knowledge work. The first is knowledge. As agents operate over longer periods, their working context accumulates history, documents, tool output, instructions, decisions, and observations until the context itself becomes part of the problem. The second is execution. Even sophisticated agents often plan the work while they are already performing it, deciding each next step through repeated model inference rather than following an explicit execution plan. As tasks become more complex, dependencies, parallelism, retries, checkpoints, failure recovery, and termination all become additional probabilistic decisions.
Put differently, today's agents struggle with both what they need to know and what they need to do. Just like a human, an agent should not have to reconstruct everything it knows from working memory each time it begins a task, nor should it improvise every step while performing the work. Relevant knowledge should be continually learned and distilled rather than indefinitely accumulated in context, while explicit execution strategies should be synthesized from complex objectives rather than worked out one action at a time. Planning and execution should therefore be separate operations. The system should understand the user's intent, synthesize a proposed execution strategy, determine what knowledge is required, and expose the plan for refinement before substantial execution begins. The plan should persist afterward so it can be evaluated, changed, versioned, rerun, reused, and improved.
The Context Window is Working Memory, Not Long-Term Memory
Modern language models have ever larger context windows, and retrieval systems can place increasing amounts of relevant information into them. It is tempting to assume that enough context plus good retrieval will solve agent memory. Research on context-length degradation suggests otherwise: performance can deteriorate as context grows even when relevant information has been retrieved. Long-horizon agents show similar effects, losing important information, making poorer decisions, or terminating prematurely. Summarization, compaction, and other context-management techniques are often presented as solutions to context growth, but they can make the underlying problem worse. Each compression step decides what matters before the system necessarily knows what will matter later, discarding detail, nuance, and weak signals that may become important downstream.
One increasingly common response is to divide complex work across sub-agents, giving each agent a smaller context and a narrower responsibility. This can be an effective way to reduce pressure on working memory, but it does not eliminate the underlying problem. It can instead create something resembling the memory problem in Memento: each new agent begins with only a partial reconstruction of what came before, relying on summaries, artifacts, messages, and retrieved state to recover enough understanding to continue the work. As tasks become longer and more interconnected, knowledge can become fragmented across agents, assumptions can diverge, reasoning may be duplicated, and important judgment can be lost in the handoffs. Sub-agents are a useful context-management technique, but distributing context is not the same as learning.
Information that remains valuable across work should eventually stop being context and become knowledge. Humans do not solve every new problem by loading a transcript of everything they have previously experienced into working memory. We learn. Experience becomes knowledge, skills, intuition, preferences, procedures, and models of the world that influence future behavior without requiring us to reconstruct the original experience each time. Agent systems need an analogous mechanism. What an agent learns should not simply be stored somewhere and retrieved back into context. Useful procedures, domain knowledge, corrections, strategies, outcomes, and patterns of decision making should increasingly be distilled through automated learning and weight updates so they become encoded across the model's neural network. This is fundamentally different from context learning. Context gives the model information to reason over temporarily. Weight-based learning changes the model itself, altering what it knows and how it responds across future interactions. The goal is not simply a larger memory system. It is a smaller, higher-quality working context backed by a continually improving model. Context management can reduce what an agent carries. Learning reduces what it needs to carry in the first place.
This matters especially for enterprise knowledge work. An agent may need to understand a company's products, customers, terminology, operating procedures, decision criteria, historical outcomes, exceptions, preferences, and unwritten institutional knowledge. Much of this information will never appear in the original training corpus of a frontier model, and continually retrieving and reconstructing it for every task is neither elegant nor necessarily reliable. Multiple specialized agents may still be valuable, but they should operate on top of durable learned knowledge rather than repeatedly rebuilding an understanding of the organization from transient context, summaries, and handoffs. Over time, the knowledge and judgment that repeatedly prove useful should become part of the model itself. An agent that works inside an organization should increasingly learn the organization.
Plan First, Then Execute - That Simple
In-model knowledge alone is not sufficient. Most agent systems combine reasoning and execution in an iterative loop: observe, decide, act, and repeat. That flexibility works for relatively small tasks. Complex knowledge work is different. Research projects, financial analyses, customer escalations, product launches, diligence processes, migrations, sales processes, and legal reviews may contain dozens or hundreds of dependent activities. Some can run in parallel, some require prerequisites, some failures should be retried, some actions require approval or verification, and some conditions should terminate an entire branch.
When those relationships remain implicit inside repeated model inference, the model is simultaneously acting as planner, scheduler, workflow engine, state machine, exception handler, and executor. Every transition becomes another probabilistic decision. Our view is that the model should synthesize the execution strategy and generate the plan, but it should not have to be the execution engine. Planning benefits from probabilistic intelligence because it involves ambiguous goals, alternative strategies, decomposition, missing information, and tradeoffs. Execution should be more controlled, with deterministic software maintaining state, enforcing dependencies, managing concurrency, retrying failures, recording provenance, applying checkpoints, respecting permissions, and testing termination conditions.
A planning-first architecture also creates a better interaction model. The user's prompt expresses intent, and the system synthesizes it into an explicit execution strategy and plan covering the work, required information, tools and models, dependencies, parallelism, validation, cost, risks, approvals, and success conditions. The user can then prompt against the strategy before resources are spent by removing an unnecessary branch, requiring a particular dataset, prioritizing cost over latency, adding verification, or correcting a misunderstanding. The plan becomes the interface between human intent and machine execution, not hidden scaffolding that disappears once work begins.
From Graph Engineering to Strategy Synthesis
Graph-based agent systems have shown why explicit workflow structure is valuable. A graph makes state transitions visible and provides natural places for deterministic behavior, branching, loops, parallelism, human intervention, checkpoints, and recovery. The limitation is that developers still determine much of the topology: which nodes exist, how state moves, where the model has discretion, and which transitions are allowed. For open-ended work, planning is often pushed back into an agent harness and improvised at runtime.
We believe there is a third approach: the system can synthesize the execution strategy. The human specifies the objective and boundaries. The system generates candidate strategies, reasons about alternatives, synthesizes an appropriate strategy, represents it as an explicit execution plan, exposes it when useful, and then compiles that plan into an executable graph for a runtime designed to execute it reliably. The graph is no longer the application that a developer authored. It is an intermediate representation produced from a synthesized strategy: something the system can validate, optimize, and execute.
Database systems provide a useful analogy. A user writing SQL describes the result they want rather than every physical operation needed to produce it. The database constructs a logical representation, applies transformations, considers alternatives, estimates cost, and chooses an execution plan. The lesson is not simply that the query plan is a graph, or even that the graph is compiled. The important abstraction is the separation between declarative intent, logical planning, optimization, and physical execution. The intermediate representation gives the system something it can reason about and optimize, with equivalent outcomes produced by plans that differ in ordering, filtering, parallelism, resource use, or risk.
Agent systems should move toward the same abstraction. A knowledge worker should describe the desired result, constraints, resources, permissions, and required quality. The system should synthesize an execution strategy from that intent, represent it as a logical plan, and then compile and optimize it into an executable form. One strategy may parallelize research, another may run a cheap diagnostic before expensive work, another may consult internal data first, require independent verification, or request approval before an irreversible action. The planner should reason about which strategy is most appropriate rather than simply asking what the agent should do next. The hard problem is not drawing the graph; it is determining the procedure the graph should represent.
Strategy synthesis also creates the possibility of a work algebra. Yes, I said it: Work Algebra. If complex knowledge work can be represented as execution plans, then many of the operations inside those plans become reusable primitives. Retrieval, comparison, decomposition, classification, estimation, verification, synthesis, simulation, critique, execution, escalation, and approval appear repeatedly across very different forms of work. Once represented explicitly, these operations can be combined, reordered, parallelized, constrained, and optimized. That also requires a richer concept of cost than tokens or runtime. Accuracy, uncertainty, expense, latency, information gain, privacy, reversibility, resources, policy, human attention, and the consequences of failure can all matter. Work Algebra therefore becomes more than an optimization vocabulary: it becomes the compositional language from which execution strategies can be synthesized. Strategy synthesis becomes a constrained, multi-objective search over possible strategies: what procedure best accomplishes the objective under the relevant constraints?
Planning Determines What Needs to Be Learned
Once a system knows what it intends to do, it can determine what it needs to know. A complex sales analysis, for example, may require understanding a company's product taxonomy, sales stages, regional structure, qualification methodology, historical definitions, internal terminology, and decision criteria. Instead of discovering these requirements piecemeal during execution and continually injecting more material into context, the system can identify learning requirements from the plan itself.
This creates a natural sequence. The user expresses intent. The system synthesizes an execution strategy and makes it explicit as a plan. The plan reveals what knowledge is required. The user can inspect and refine the plan. The system performs the necessary learning, then execution begins. The plan provides a signal about what knowledge actually matters, which means the system does not need to learn everything. It needs to learn what improves its ability to perform the work it has been asked to perform.
Plans Should Persist, Adapt, and Improve
Execution should not be the end of the plan. If the plan persists, a user can inspect what happened, modify the relevant part, create a new version, and potentially rerun only the portions affected by the change. The process begins to look less like repeated prompting and more like iterative development. A plan is generated and executed, the outcome is evaluated, the plan is refined, and a new version runs. The system is improving a reusable mechanism for performing work rather than simply having another conversation.
Once plans and learned knowledge persist, agents can become reusable, versioned objects. An organization could clone an effective agent and adapt it for a related purpose while preserving useful domain knowledge, planning strategies, tools, sources, and expert corrections. Different versions could evolve independently, with lineage, forks, rollback points, specialized variants, and histories of improvement. What is being versioned is not simply a prompt, but a way of understanding a domain and performing work within it.
Execution also creates experience that should improve future behavior. Every run reveals which tools were reliable, which branches were unnecessary, which estimates were wrong, where the workflow stalled, which corrections occurred, and how closely the outcome matched the objective. Some of that experience should improve planning, some should become organizational knowledge, and some should become training signal. Over time, the system can accumulate both declarative knowledge about what the organization knows and procedural intelligence about how it effectively gets work done, improving not only what it knows but the strategies it synthesizes for future work.
Plans must still adapt when reality changes. New evidence may invalidate an assumption, a tool may fail, or an expected resource may be unavailable. The difference is that replanning becomes explicit. The execution graph represents the best current hypothesis about how to accomplish the objective. When reality invalidates part of that hypothesis, the system can resynthesize the affected portion of the strategy and recompile the corresponding portion of the execution graph instead of drifting into a different sequence of actions through unconstrained runtime improvisation. This preserves flexibility while making adaptation observable and controlled.
Why This Matters for Knowledge Workers
Real knowledge work rarely fits neatly into predefined workflows. Organizations encode their processes through applications, spreadsheets, playbooks, checklists, meetings, operating procedures, and tribal knowledge. Today, turning that messy reality into reliable autonomous AI workflows generally requires engineers to translate it into prompts, retrieval pipelines, tools, agent graphs, state machines, context-management strategies, retry logic, and exception handling. That cannot be the final interface for AI-powered knowledge work.
Consider commercial credit. An AI system can retrieve financial statements, collateral data, industry research, customer history, lending policies, and risk models, but an experienced credit officer often brings something that is much harder to retrieve: years of tacit judgment. The officer may recognize that a technically acceptable assumption is unrealistic, that the combination of revenue concentration and management history deserves deeper scrutiny, or that a seemingly minor relationship changes the character of the risk. Much of this intuition was learned through exceptions and outcomes rather than written into a policy manual.
In a planning-first system, that expert should not appear only at the end to approve or reject an answer. The expert can reshape the plan by adding an investigation, changing how evidence is weighted, requiring independent verification, or introducing a scenario analysis before execution continues. Those interventions are not merely safety checks. They are potentially valuable learning signals. Over time, the system can turn repeated expert corrections and decisions into durable organizational capability, capturing not just what the organization knows but part of how its best people exercise judgment.
If participating in the AI revolution requires every knowledge worker to become a graph engineer, prompt engineer, context engineer, or workflow developer, the abstraction is wrong. A knowledge worker should be able to express what they are trying to accomplish. The system should determine what it needs to know and how the work should be performed, show the plan when useful, learn what is necessary, execute reliably, evaluate the result, and improve. Humans can collaborate before execution by shaping the plan, during execution by handling exceptions and consequential decisions, and afterward by correcting not just the output but the mechanism that produced it.
Beyond Graph Engineering
Graph engineering is an important step in the evolution of agent systems, but it should not be the destination. The larger transition is from humans engineering execution graphs to systems synthesizing strategies for accomplishing objectives, from agents accumulating larger working contexts to agents continually learning durable knowledge, and from planning as invisible runtime state to planning as a persistent artifact that can be inspected, changed, versioned, reused, and improved. Compilation and optimization still matter, but they become downstream steps that transform a synthesized strategy into reliable execution.
At LatentSpin, we think about this as a new lifecycle for autonomous work. A user expresses intent. The system synthesizes a strategy for accomplishing the objective, determines what must be learned, and exposes that strategy as an explicit plan for refinement. It learns what is necessary, compiles and optimizes the plan into an execution graph, and runs it through a reliable runtime. The outcome is evaluated, the plan can be revised, and experience improves both what the system knows and how it approaches future work.
The result is a system that can learn what it needs to know, synthesize how work should be performed, execute that strategy reliably, and improve through experience. Autonomous work requires more than agents that can reason about the next step. It requires systems that can determine how an objective should be accomplished and become better at the work over time. We believe that architecture is necessary to make autonomous AI practical for the world's knowledge workers.