LLM Agents Need a Cognitive Grammar, Not Just More Tools

Most agent systems today are built around tools, prompts, memory, routing, graphs, and orchestration.

That is useful, but I think something important is still missing.

The reasoning patterns that actually determine agent behavior often remain buried inside prompts, callbacks, tool loops, framework-specific nodes, or application glue.

An agent may evaluate evidence, surface uncertainty, compare options, update memory, forecast consequences, or decide whether an action should proceed.

But where does that reasoning live?

Can it be reused?

Can it be tested?

Can it be traced?

Can another agent execute the same reasoning pattern in a different opportunity?

That is the problem I am trying to address with ORCA.

From more tools to a cognitive grammar

Tools are operations. They retrieve a document, call an API, write a file, send a message, query a database, or trigger a workflow.

But many of the most important parts of agent behavior are not operations in that sense.

They are reasoning patterns.

For example:

• evaluate evidence;
• identify uncertainty;
• compare alternatives;
• detect missing information;
• classify risk;
• reconcile memory;
• forecast consequences;
• decide whether an action should proceed.

These patterns may use tools. They may call models. They may involve deterministic code, rules, retrieval, policies, or human approval.

But they are not just tools.

They are reusable cognitive structures.

That is why I think LLM agents need something like a cognitive grammar: a way to express not only what operations an agent can call, but how selected reasoning processes are composed, executed, inspected, and governed.

COGITs: bounded cognitive acts

In ORCA, I call the basic unit a COGIT.

A COGIT is a bounded executable cognitive act with a defined purpose, inputs, outputs, validation expectations, and trace semantics. It has by definition enough granularity to be executed without excesive risk and high enough cognitie level to capture a reusable cognitive process.

Examples:

• extract uncertainty from a request;
• classify the risk level of an action;
• detect evidence gaps;
• compare options against criteria;
• update memory context;
• forecast consequences;
• select a continuation decision.

A COGIT is not necessarily an LLM prompt. It can be implemented with an LLM, deterministic code, a rules engine, an external API, or a hybrid backend.

The important point is that the cognitive contract remains stable even if the backend changes.

SYLLOGs: executable cognitive compositions

Many useful reasoning processes are not single steps.

For example, “make a decision” may involve:

1. normalizing the request;
2. generating options;
3. evaluating tradeoffs;
4. surfacing uncertainty;
5. scoring options;
6. justifying the recommendation;
7. validating the output.

“Think before acting” may involve:

1. modeling the candidate action;
2. identifying affected entities;
3. extracting constraints;
4. surfacing uncertainty;
5. assessing risk;
6. forecasting consequences;
7. generating safer alternatives;
8. selecting whether to proceed, revise, escalate, or block.

These are not just prompts.

They are structured reasoning paths. In ORCA, I call these compositions SYLLOGs.

A SYLLOG is an executable composition of COGITs. If COGITs are bounded cognitive acts, SYLLOGs are cognitive programs.

Why this is not about hidden chain-of-thought

The goal is not to expose the model’s hidden mind. The goal is to require the agent system to execute certain cognitive procedures when they matter. That distinction is important.

We usually cannot access the true internal reasoning process of a model. We can ask for a rationale, but that rationale is another generated artifact, not a reliable trace of the cognition that produced an action.

ORCA takes a different approach, and the difference is architectural.

Instead of trying to recover the model’s hidden chain of thought, it defines external cognitive procedures that the agent system can require, validate, and trace.

The trace is not:

What did the model secretly think?

The trace is:

What cognitive procedure did the agent system require before producing this decision or allowing this action path to continue?

Why not just use graph nodes?

Of course, these patterns can be implemented as nodes in an existing graph framework.

That is not the interesting question. The interesting question is whether the reasoning pattern has a portable cognitive contract independent of the graph that happens to execute it.

Without that contract, the pattern remains application glue.

With that contract, it can become a reusable artifact.

A framework graph may describe execution.

A cognitive grammar describes reusable reasoning.

Those two things can work together, but they are not the same abstraction.

A concrete example: Action Preflight

One concrete SYLLOG is Action Preflight.

The idea is that an LLM agent should not move directly from:

I intend to do X

to:

I executed X

There should be a cognitive path in between.

Before an agent sends a message, calls an API, edits a file, accesses private data, triggers a workflow, or delegates work, the system should be able to require a structured pre-action reasoning path.

Action Preflight attempts to make the candidate action explicit:

candidate action
→ action model
→ affected entities
→ constraints
→ uncertainty
→ risk
→ plausible consequences
→ safer alternatives
→ continuation decision

figure1_action_preflight_syllog1122×1402 267 KB

Great post. The distinction between “tools” and “reusable reasoning patterns” (COGITs/SYLLOGs) is crucial for moving from hacked-together agents to reliable industrial systems.
However, there is a fundamental layer often overlooked in purely architectural or symbolic approaches: the internal dynamic stability of the model during the execution of these patterns.
As an independent researcher working on the dynamic observability of LLMs, I see a direct convergence with your approach. You define the logical structure; my work focuses on validating the physical stability of that structure’s execution.

1. The Problem of the “Executive Black Box”
   You state: “We usually cannot access the true internal reasoning process of a model… ORCA defines external cognitive procedures.”
   This is correct. ORCA defines the WHAT (the structure of reasoning: evaluate, compare, decide).
   But who validates the HOW (the cognitive state of the model while executing these steps)?
   An agent can perfectly execute a “Action Preflight” SYLLOG according to your grammar, but if the underlying model enters a regime of geometric instability during the “forecast consequences” step, the result will be a confident hallucination or semantic drift, even if the logical structure is respected.
   My research demonstrates that this instability is not random noise, but a predictable dynamic regime characterized by high trajectory curvature and entropy shifts (Four Dynamical Regimes, V19/V20).
2. Complementarity: Grammar vs. Dynamics
   My work on LIMEN (Liminal Internal Metric for Emergent Navigation) and VBE (Validation Before Execution) brings the layer of dynamic validation missing from purely symbolic approaches:
   ORCA (Cognitive Grammar): Externalizes and structures reasoning into reusable blocks (COGITs). This is the logical skeleton.
   LIMEN/VBE (Dynamic Observability): Measures in real-time the coherence of the model’s internal trajectory. This acts as a stability monitor, detecting when the model’s internal state diverges from a stable path, regardless of the prompt structure (Dynamic-Layer Controllability, V21).
   The Analogy:
   ORCA is the GPS tracing the ideal route (the reasoning plan).
   LIMEN/VBE is the stability control system that detects if the car (the model) is skidding, even if it’s following the mapped route.
3. Towards a Dynamically Auditable “Cognitive Contract”
   You mention the “Cognitive Contract”. For it to be truly robust, it must include a dynamic dimension:
   Structure (ORCA): The agent must pass through steps A → B → C.
   Stability (LIMEN): At each step, the model’s internal trajectory must remain within stable dynamic bounds (low curvature, consistent entropy).
   Proof (Checkpoints): Each transition is logged with its stability metrics, creating an auditable trail of cognitive health (Conditional Dynamic Signatures, V22).
   If step B generates a high instability score, the system shouldn’t just “trace” the error; it must block execution before the action is committed.
   Conclusion
   “Cognitive Grammar” is essential for reusability.
   “Dynamic Observability” is essential for safety.
   They do not oppose each other; they complement each other. A mature industrial agent will need a grammar to structure its thought (ORCA) and a dynamic monitor to guarantee its operational stability (LIMEN/VBE).

Thanks, this is a very interesting framing.

I agree with the distinction between the logical structure of cognition and the quality or stability of the model execution underneath it.

The way I think about ORCA is not as a claim that structure alone is sufficient. ORCA externalizes the reasoning procedure: what cognitive acts must happen, in what order, with what inputs, outputs, contracts, validation points, and traces. But each COGIT still needs an execution backend, and that backend can fail in different ways: hallucination, semantic drift, overconfidence, instability, weak grounding, or inconsistent interpretation of the contract.

So yes, there is a meaningful difference between:

1. Did the agent execute the required cognitive path?
2. Was each step executed reliably by the underlying model/backend?

ORCA is mostly focused on the first problem, while creating explicit places where the second problem can be tested, validated, or blocked under a limited scope where the second problems gets less complicated.

Where I would be slightly careful is in calling ORCA “purely symbolic.” The COGIT/SYLLOG layer is structural, but it is not meant to assume symbolic execution only. A COGIT can be backed by an LLM, deterministic code, retrieval, a rules engine, a classifier, a verification model, a policy check, or some hybrid mechanism. In that sense, a dynamic stability monitor could itself become part of the runtime validation layer.

For example, a consequence-forecasting COGIT could produce its normal structured output, while an additional validator evaluates whether the execution was stable enough to trust. If the stability signal is bad, the SYLLOG should not blindly continue. It could re-run, switch backend, reduce scope, request clarification, escalate to a human, or block the action path.

So I like your GPS / stability-control analogy. I would phrase the relationship as:

ORCA defines the cognitive route and the checkpoints.
A dynamic observability layer could evaluate whether the model is still executing each segment in a trustworthy regime.

That would fit very naturally with the idea of cognitive contracts. A mature contract should probably include not only input/output schema and semantic validation, but also execution-quality signals: confidence, uncertainty, grounding, consistency, drift, and, where available, model-dynamic stability.

The key architectural point for me is that these signals become useful because the cognitive process has been segmented. If the whole task is one large prompt, it is hard to know where instability matters or what to do with it. If the process is decomposed into bounded COGITs, then stability can be checked at meaningful transition points.

So yes, I see the two ideas as complementary:

• ORCA: makes selected reasoning procedures explicit, reusable, and traceable.
• LIMEN/VBE-style monitoring: could provide execution-health signals for the model/backend running those procedures.

The combination would be stronger than either alone: structured cognition plus runtime evidence that the execution of each cognitive step remained within acceptable bounds.

lets try a test

do you have a repo i can check?

I agree with the idea of moving the composition, execution, inspection, and governance of reasoning processes outside the model, but I wonder if we’re reaching for a more elaborate abstraction than necessary in some cases.

Before governing a “cognitive grammar,” there’s a simpler problem: explicit state. What premises currently hold? What constraints apply? What has been superseded? What is unresolved? What conditions permit a state change?

If that remains implicit in the context, then even an externally governed reasoning process is still relying on the model to reconstruct the state it is reasoning over.

I suspect explicit, host-governed state gets us surprisingly far before we need a grammar of cognition.

llm is 1 turn model. the problem is the finite arquitecture, we are treatng lanaguage processors like entities and are not. our research discover a new direction.

I agree with this. Explicit state is probably the first layer that needs to be externalized.

My view is that ORCA should not be understood as “cognitive grammar instead of state,” but as a way to define bounded cognitive operations over explicit host-governed state.

In other words, each COGIT should not just be a named reasoning step. It should have a clear state contract:

• what inputs it reads

• what assumptions it depends on

• what constraints it must respect

• what evidence it used

• what uncertainties remain

• what state changes it is allowed to make

• what conditions allow the workflow to continue, retry, branch, or stop

Without that, I agree that the model is still reconstructing too much from context.

So the layered view is:

1. Explicit state: premises, constraints, unresolved questions, superseded claims, evidence, uncertainty.

2. State transitions: host-governed rules for what can change and when.

3. COGITs: bounded cognitive operations that transform or evaluate that state.

4. Skills/workflows: reusable compositions of those COGITs.

5. Governance/monitoring: validation, tracing, policy, and execution-health signals around the transitions.

From that perspective, ORCA is not trying to replace explicit state with a cognitive grammar. It is trying to make reasoning procedures composable once the state they operate on is explicit enough to be governed.

I agree that treating the model as an autonomous entity is misleading.

A base LLM is closer to a stateless language processor invoked turn by turn. The apparent continuity comes from the host system: context, memory, tools, orchestration, state management, and execution policy.

That is exactly why I think the reasoning process should not live entirely inside the model. The host should externalize the parts that need persistence, inspection and governance: state, assumptions, constraints, evidence, uncertainty, transitions and task structure.

In that sense, ORCA is not trying to make the model into an entity. It assumes the opposite: the model is a cognitive executor for bounded operations, while the system owns the state and the process.

I would be interested in understanding what you mean by “finite architecture” and what the new direction is in operational terms. Is it a different runtime model, a state architecture, a non-turn-based inference loop, or something else?

I know it’s hard to listen to an unknown voice in a forum, but bear with me.

The LLM is a finite architecture — it was designed that way. It’s a one-turn model. To simulate that it’s persistent or has memory, we’re modeling absurd solutions like reinjecting tokens. It looks logical, but it isn’t: the model reads everything, all the documents, the whole history, before responding again. Because in reality it has no presence and no persistence. It knows nothing. It’s just a turn.

To simulate that it “understands” us, we reinject. But reinjection has a limit — the bigger the context and space, the harder it becomes to manage. That’s why, as of today, there are no real functional agents. They all break and require constant supervision. Memory systems build summaries, but if the summary isn’t good, you get drift. It’s the telephone game — I tell you something, you retell it, and there are models that drift after 6 exchanges and all of them break after 300 to 900. Unless it’s a cron of repetitive tasks — but if that’s the case you don’t need AI, you can use n8n with a cron.

AI is a car without wheels, and companies are obsessed with adding mirrors, reclining seats, GPS, power steering, air conditioning. You now need a postgraduate degree to understand Claude, which already has more than 15,000 configuration knobs. The promise of AI was that it would understand us and we could work with it. That’s not happening. What’s happening now is prompt engineering — digital stress.

The model is reaching its limit. AGI will never emerge from this path, because for AGI to exist you need presence.

The problem with the car is that it has no wheels. Dragging it with a horse and pretending it moves is a bit absurd. That’s what we’re doing: a car without wheels that isn’t going anywhere, and we’re pulling it with a horse saying “look! I moved it!” Everyone, everyone, everyone is doing the same thing. The problem isn’t the horse or the rope you’re pulling with. The problem is that the car has no wheels.

And that — briefly — is Trinity PPAi. A new architecture where there are no turns. Only presence. It’s like the difference between night and day.

I can’t say much more about it. I tried to get Hugging Face to create a space for us, because we didn’t invent a model or a fine-tune. We invented a new persistent architecture that solves the problem at its root.

A car with wheels.

That is exactly why I think the model should not own continuity; the host should own state and process, while the model executes bounded cognitive steps over that state.

I’ve been experimenting with explicit state, and I’ve come to a couple of conclusions that may be relevant here.

1. At the end of the day, an LLM is probabilistic. Even if the state itself is maintained deterministically outside the model and reinjected on every turn, the model’s interpretation and application of that state are still probabilistic.
2. The host and the model don’t necessarily share the same concept of authority. System prompts, developer prompts, message roles, and other techniques can help communicate that some information should be treated differently. But if a particular premise or constraint must remain authoritative, we’re still relying on a nondeterministic model to interpret and apply that authority correctly.

That’s what pushed me toward thinking that explicit state alone isn’t quite enough. The state can be deterministic, but anything that actually matters to correctness may also need to be enforced at the host boundary rather than relying solely on reinjection into the model.

I agree with the underlying problem you’re pointing at, although I’m not sure I reach exactly the same conclusion.

I don’t think persistence necessarily has to live entirely inside the model. A larger system can provide continuity, maintain authoritative state, and control what actions are allowed.

That said, I do wonder whether some concept of persistence or state needs to be reflected in training. Right now we can give a model ordinary information and critically important persistent state, but ultimately both are inputs the model has to interpret. Perhaps models need to be trained to distinguish more explicitly between “this is information” and “this is state that should continue to govern future behavior.”

That would still be probabilistic, but the probabilities could potentially be made much more favorable.

I also see the car analogy a little differently. The LLM isn’t a car without wheels. It already goes somewhere, sometimes remarkably quickly. What we’re still building are the steering (structured outputs and constrained decoding), brakes (human-in-the-loop approval and execution authorization), and instrumentation (tracing and observability) needed to make that movement reliable and useful.

Two things.

On training the model to distinguish “information” from “state that should govern future behavior”: no. Persistence isn’t a content problem, it’s an architectural problem. And the LLM architecture, as such, doesn’t exist for that — it’s a text processor. Brilliant, evolved, impressive, but that’s what it is: a one-turn text processor. Training it better doesn’t change what it is.

On the analogy: the LLM doesn’t move. It’s static. It gives good one-off answers and on paper it looks spectacular, but taking it to the real world hasn’t worked. As of today there is no LLM-based agent that executes stable, medium-term persistent tasks. They all break, they all require constant supervision, they all drift.

Give an LLM a task. It has no importance to it. It won’t do it, it won’t continue it. On every turn it forgets the direction you gave it. To make it “do something” you have to add a cron, or a complex memory system, or an orchestrator that tells it again, every turn, what it was doing. That is not an agent executing a task. It’s a text processor being reminded, turn by turn, by an external system, that a task exists.

That’s why the metaphor is precise. A car goes somewhere, holds a direction until it reaches a destination. An LLM has no destination. Adding steering, brakes, and instrumentation doesn’t give it a destination — it gives it a better-supervised turn.

In the PPAi category I have a complex persistent task, with more than 20 distinct activities, running across hundreds of thousands of interactions. No drift. That’s not scaffolding on top of an LLM. It’s something else.

I think we’re drawing the system boundary in different places.

A CPU doesn’t execute a persistent task by itself either. It’s repeatedly given instructions while RAM, storage, and the operating system maintain state and coordinate execution. But we don’t conclude that computers can’t execute persistent tasks because persistence doesn’t live inside the CPU.

I see the LLM similarly: it can be one component of a persistent system without persistence having to live entirely inside the model itself.

Agreed on the structural point — a CPU doesn’t hold persistence either, and nobody calls the CPU “the computer.”

Where I’d push back is that this isn’t what the industry is actually building. Today’s agents treat the LLM as the computer — CPU, RAM, OS and application at once, with a cron bolted on. That’s why they break.

Drawing the boundary properly, the way you’re describing it, is the work. It’s not the default.

Yes, that is exactly the distinction I’m trying to make: explicit state is necessary, but not sufficient; anything that must remain authoritative should be enforced at the host boundary, not merely reinjected and left for the model to probabilistically interpret.

This is exactly the boundary ORCA is trying to formalize: the LLM is not the agent; it is one executor inside a host-governed system that owns state, process, validation, memory and execution.