LLM Agents Need a Cognitive Grammar, Not Just More Tools

A developer proposes ORCA, a cognitive grammar for LLM agents that defines reusable reasoning patterns called COGITs and SYLLOGs, aiming to make agent behavior more traceable, testable, and portable beyond current tool-based frameworks.

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. 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: 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. 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: 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. Many useful reasoning processes are not single steps. For example, “make a decision” may involve: “Think before acting” may involve: 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. 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? 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. 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