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:
- normalizing the request;
- generating options;
- evaluating tradeoffs;
- surfacing uncertainty;
- scoring options;
- justifying the recommendation;
- validating the output.
“Think before acting” may involve:
- modeling the candidate action;
- identifying affected entities;
- extracting constraints;
- surfacing uncertainty;
- assessing risk;
- forecasting consequences;
- generating safer alternatives;
- 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
