Most agent frameworks treat goals as strings. A prompt says “help the user book a flight,” the LLM generates actions, and when the actions stop, the goal is done. There’s no memory of the goal, no tracking of what blocks it, no emotional weight to pursuing it, and no way to compare it against competing goals. The goal exists for the duration of one request and vanishes.

This is like building a person who can only think about one thing at a time and forgets it the moment they look away.

I’ve spent the last two days designing what comes next: a cognitive goal system where goals are persistent, structured, emotionally weighted, and progressively detailed. Not a TODO list — a model of how wanting something actually works.

The problem with “goal” as a string

Our platform already had goals. Four different kinds, in four different repos, all using the same word.

Eidos AgentGoal "what the agent IS for" Engine Goal (predicate) "when is the case done?" Blocks DriveGoalProposal "what drives want" Desiredstate GoalCompiler<G> "compile to state graph" Neocortex Cognitive goals — the gap "what does wanting this INVOLVE?" Four kinds of "goal" feeding into a cognitive layer that didn't exist

Eidos stores standing goals on an agent’s descriptor — “find the diamond,” “protect Penelope.” Identity metadata. Engine evaluates goal predicates against case state — .decision == "approved" fires a GoalReachedEvent and the case completes. Blocks proposes goals from motivational drives — curiosity is high, so propose “explore the library.” Desiredstate compiles goals into provisioning DAGs with dependency ordering.

Each layer does something legitimate. None of them tracks what pursuing a goal involves, what blocks it, how it feels, or whether two goals share sub-goals that could be done once.

That’s the cognitive gap. And it’s the gap that separates an agent that executes goals from one that thinks about them.

Three dimensions of wanting

The architecture we landed on has three interacting goal dimensions — not a hierarchy, not a unified type, but three complementary systems.

LLM Goals Prose. Drives propose them. LLM decomposes recursively until steps bind to capabilities. blocks / langchain4j "explore quantum computing" Case Goals Predicates over state. Machine-evaluated. Cases ARE goal pursuit. engine ".approved == true" Cognitive Goals Knowledge graph nodes. Affect. Dependencies. Priority. Progressive resolution. Consolidation-managed. Manages and enriches both. Also standalone. neocortex (NEW) "this goal is blocked, frustrating, and shares sub-goals with that one" propose outcomes

LLM goals are prose. An agent’s drive system generates “explore the library” — natural language, interpreted by an LLM, recursively decomposed until sub-steps bind to concrete capabilities. This is what blocks does today through GoalProposalOrchestrator with its four drive-to-goal mappers and LLM formation strategy.

Case goals are predicates. .decision == "approved" evaluates mechanically against case state. When it fires, the case transitions. The original engine research (ADR-0001) nailed this: “A goal is a predicate over state, not a checklist of tasks that ran.” Cases are goal pursuit — you want something, you run a case, it completes when the predicate is satisfied.

Cognitive goals are knowledge. This is the new layer. A cognitive goal lives in the knowledge graph (MindMap) as a node with affect (how does pursuing this feel?), dependencies (what blocks it? what does it enable?), confidence, temporal horizon, and lifecycle state. The cognitive layer manages and enriches goals from both other dimensions — when a drive proposes a goal, the cognitive layer tracks it; when a case completes, the cognitive layer updates goal status and models the affective response.

The three dimensions have genuinely different evaluation mechanisms. LLM goals are interpreted by language models. Case goals are evaluated by predicate engines. Cognitive goals are managed by graph reasoning with affect modulation. Trying to unify them into a single type would conflate three concerns that serve different purposes at different timescales.

The brain analogy that actually holds

While working through the dependency relationships between our repos, a structural analogy emerged that I think is more than metaphorical.

Neocortex = Cerebral Cortex Memory. Knowledge graph. Affect. Goals. Beliefs. Stores everything. Processes nothing behaviorally. The brain's memory substrate Blocks = Motivational Circuit Drives. Goal proposal. Narrative. Reads state → evaluates → decides. Hypothalamus + basal ganglia Engine = Motor Cortex Plan dispatch. Case execution. Action selection + execution RAS Sensory gate reads writes Neocortex stores. Blocks processes. Engine executes. RAS filters.

Neocortex is the cerebral cortex — all persistent cognitive state. Memory, knowledge graph, affect trajectories, goal dependencies, beliefs. It stores everything but makes no behavioral decisions.

Blocks is the motivational circuit — hypothalamus (drives), basal ganglia (action selection). It reads cognitive state from neocortex, evaluates drives, composes motivational signals, proposes goals, renders prompts. Critically: it stores nothing. It’s a pure evaluate→decide loop. All persistent state lives in neocortex.

Engine is the motor cortex — plan dispatch, case execution, action selection. When blocks decides to pursue a goal, engine decomposes it into executable steps and dispatches them.

RAS is the sensory gate — filtering what reaches cognition.

The key constraint: neocortex defines SPIs (service provider interfaces) for cognitive operations that need LLMs — goal decomposition, goal recognition, belief revision. Blocks provides the LLM implementations. Neocortex compiles and runs without blocks; blocks plugs in when present. This maps to how the cortex defines what processing is needed, while the motivational system provides the activation energy.

Progressive resolution: LOD for knowledge

Here’s the idea I’m most excited about.

Graphics rendering solved the “how much detail?” problem decades ago with level-of-detail: render nearby objects at high fidelity, distant objects as low-poly placeholders (Clark, 1976). The same principle applies to goal knowledge.

Not all goals need the same structural detail. A goal’s resolution should depend on how close it is to requiring a decision:

NOW FAR FUTURE Deploy v2.0 tests docs infra review HIGH resolution Hire senior eng JD pipe eval MEDIUM Open Tokyo office LOW — single node Resolution increases as goals approach decision points Consolidation sleep cycle manages both directions: EXPAND approaching goals ←→ PRUNE receding goals MERGE shared sub-goals across parents

“Deploy v2.0” is imminent — it gets full decomposition: sub-goals for tests, docs, infrastructure, review, with dependency edges between them. “Hire a senior engineer” is a few months out — rough decomposition, enough to estimate scope. “Open Tokyo office” is aspirational — a single node with a prose description. No sub-goals. No point.

The resolution is managed by the consolidation sleep cycle — the existing background timer that runs maintenance phases when the system is idle. During “sleep,” the GoalResolutionPhase:

  • Expands goals that are approaching (time proximity, rising urgency) — invokes an LLM-based cognitive decomposition SPI to generate sub-goals
  • Prunes goals that have receded — collapses detailed sub-graphs back to single nodes when the detail hasn’t been accessed
  • Merges shared sub-goals across parents — two goals like “understand customer pain points” and “assess user frustration areas” are semantically equivalent despite lexical distance. Embedding similarity catches what name matching can’t
  • Revises dependency state — if a blocker is resolved, the blocked goal transitions back to active
  • Decays dormant goals — reducing priority and suggesting abandonment when affect declines

This mirrors what human sleep actually does — prune irrelevant detail, strengthen relevant connections, surface relationships that weren’t obvious during waking cognition (Walker, 2017). We already had the consolidation scheduler. We already had the idle detection. The goal resolution phase slots into the existing infrastructure at priority 35, between merge detection (20) and curiosity signals (40).

Cognitive vs execution decomposition

A critical distinction: what the cognitive system produces is thoughts, not tasks.

When neocortex decomposes a goal, it asks: “what does achieving this involve?” The output is prose sub-goal nodes in the knowledge graph — “understand current pain points,” “reduce response time,” “build trust through consistency.” No agent assignment. No output contracts. No contingency plans.

When engine decomposes a goal for execution, it asks: “how do I execute this?” The output is a DagPlan with agent-assigned task nodes, capability bindings, judgment gates, and contingency plans. This is execution planning — finer-grained, agent-specific, disposable after the case completes.

  Cognitive (neocortex) Execution (engine)
Question “What does this involve?” “How do I execute this?”
When Early — to understand structure Late — when submitted for execution
Output MindMap nodes (prose + affect) DagPlan (agent tasks + contracts)
Persistence Persistent, variable resolution Per-case, discarded after

Two decompositions. Different questions. Different timescales. The cognitive structure informs goal selection — “which of these competing goals should I pursue?” — while the execution structure informs goal dispatch — “which agent does what step?”

This separation is grounded in the BDI architecture (Rao & Georgeff, 1995): desires (what the agent wants) are distinct from intentions (what the agent is committed to doing about it). Soar (Laird, 2012) takes it further — subgoaling is cognition. You don’t decompose goals preemptively; you decompose when you hit a decision point that requires understanding structure. ACT-R (Anderson, 2007) adds that the current goal biases retrieval — what you’re trying to achieve shapes what memories you can access.

Goals have feelings

Appraisal theory (Scherer, 2001) models goals as reference points for emotional evaluation. How you feel about a situation depends on its relationship to your goals. We implement this directly.

Each cognitive goal node carries PAD emotional dimensions (pleasure, arousal, dominance). A GoalAffectPhase runs during consolidation and computes anticipated affect:

  • High urgency + approaching deadline → increased arousal (stress, energy)
  • Blocked + important → frustration (negative pleasure, high arousal)
  • Recently completed → satisfaction (positive pleasure shift)
  • Dormant + declining interest → reduced arousal, fading priority

These affect values feed into the existing AffectTrajectoryAnalyzer — the same pipeline that tracks mood, emotion, and personality across the agent’s lifetime. Goal-related affect becomes one more signal in the agent’s emotional landscape.

La VIDA (Addison, 2025) shows that goal-self concordance — how well a goal aligns with the agent’s personality — is an optimisation criterion for goal selection. Our CognitiveDefaults already derive personality weights from disposition axes. An agent with high curiosity naturally gravitates toward exploration goals. An agent with high affiliation prioritises relationship-building goals. The priority computation weights urgency, feasibility, affect, and structural importance — with personality determining the relative weighting.

The interface is narrow

One concern I had going in: would the cognitive layer create tight coupling between neocortex, blocks, and engine?

The answer is no. The interface is deliberately narrow:

Neocortex → Engine:  GoalFormationService.propose(prose + priority)
Engine → Neocortex:  ExperienceEvent (case outcomes)

That’s it. Neocortex submits goals for execution through the existing formation SPI — the same one blocks already uses. Engine outcomes flow back as experience events — the same pipeline that already feeds memory and consolidation. No shared graph types. No shared goal records. No new coupling.

The cognitive goal graph lives in MindMap. Engine’s execution plans live in DagPlan. The two systems communicate through goal submission (prose description + priority) and outcome feedback (experience events). Each system can evolve independently.

What’s built

The full cognitive goal substrate is committed. Eidos gains GoalLifecycleState and GoalHorizon on AgentGoal (backward compatible — nullable fields). Neocortex mindmap-api gains the GOAL subgraph type, GoalVocabulary (five edge types with aliases), and three SPIs with NoOp defaults.

The Goallike trait interface replaces the placeholder Intentionlike with seven property accessors — description, status, horizon, origin, resolution, urgency, feasibility. Intentionlike and Desirelike are deprecated. In the type hierarchy, “intention” and “desire” become subtypes of “goal” — LLM extraction that produces either label now maps to the unified goal type.

Four consolidation phases slot into the existing sleep cycle: GoalResolutionPhase (priority 35) runs the five-step cycle — prune, expand, merge, revise, sync. GoalAffectPhase (37) computes anticipated emotion. GoalPrioritizationPhase (38) applies the composite priority formula. GoalRecognitionPhase (45) scans experience memories for implicit goals the agent hasn’t consciously tracked.

Goal-conditioned retrieval works through a GoalRelevanceModulationFactor — a BFS walk from each memory’s entity node to active goals, with distance-decayed weights. One edge away: full weight. Two edges: 0.7. Three: 0.4. Four or more: invisible. When an agent is pursuing something, memories near that pursuit surface more readily. When nothing is active, retrieval is neutral.

One thing I noticed during implementation: the design anticipated needing an eidos-api dependency in mindmap-intelligence for lifecycle sync. We didn’t. The GoalLifecycleProvider SPI returns Map<String, String> — status strings, not eidos types. The module boundary held cleaner than expected. Mindmap-api stays zero-deps.

The bigger implication crystallised during the design work: all of blocks’ social cognition state — mental models, user profiles, narratives, strategy profiles — is cognitive memory that belongs in neocortex. Blocks built it because neocortex didn’t have the infrastructure yet. Now it does. The follow-up epic (#378) will migrate that state, making blocks a pure processor — reads state, evaluates, decides, writes back. The brain’s motivational circuit: processes memories, doesn’t store them.

The platform is developing a nervous system. RAS for sensing. Neocortex for remembering and reasoning. Blocks for wanting and deciding. Engine for doing. Each layer cleanly separated, each doing what brains figured out millions of years ago: separate what you know from what you want from what you do.


References

  • Anderson, J.R. (2007). How Can the Human Mind Occur in the Physical Universe? Oxford University Press. — ACT-R: goal as working memory focus that biases retrieval
  • Addison, E. (2025). “La VIDA — Motivated Goal Reasoning Agent.” Autonomous Agents and Multi-Agent Systems. — Goal-self concordance from personality
  • Clark, J.H. (1976). “Hierarchical Geometric Models for Visible Surface Algorithms.” Communications of the ACM. — Original level-of-detail concept
  • Laird, J.E. (2012). The Soar Cognitive Architecture. MIT Press. — Subgoaling as cognition, impasse-driven decomposition
  • Park, J.S. et al. (2023). “Generative Agents: Interactive Simulacra of Human Behavior.” — Goal-directed daily planning from reflection
  • Rao, A.S. & Georgeff, M.P. (1995). “BDI Agents: From Theory to Practice.” ICMAS. — Desire/intention separation, deliberation cycle
  • Scherer, K.R. (2001). “Appraisal Considered as a Process of Multilevel Sequential Checking.” Appraisal Processes in Emotion. — Goals as reference points for emotional evaluation
  • Walker, M.P. (2017). Why We Sleep. Scribner. — Sleep consolidation: pruning, strengthening, discovery

<
Previous Post
Expression tiers that don't trap you
>
Next Post
Reporting for auditors — from data services to offline verification