From Prompt Engineering to Context Engineering: Why Typed Graphs Beat Chatty Agents in the Lab

A lab workflow is a terrible place to discover that your AI agent has been “remembering” chemistry as a conversation.

That sounds unkind. It is also the point.

In a casual chatbot, losing track of context means an awkward answer. In computational chemistry, losing track of context can mean a wrong molecular geometry, a missing imaginary-frequency check, an invalid charge or multiplicity, or a pKa estimate that looks numerically confident while being scientifically useless. The model did not necessarily become stupid. The workflow around it treated state as text.

The paper El Agente Gráfico: Structured Execution Graphs for Scientific Agents makes a useful argument for the current agent debate: the next step is not always “more agents,” “better prompts,” or “larger models.” Sometimes the missing layer is much more boring, and therefore much more important: typed execution state, schema-constrained transitions, and persistent graph memory.¹

In other words, the agent should not carry a laboratory notebook in its short-term chat history and hope for the best. Hope remains a poor orchestration primitive. Charming, perhaps. Not scalable.

The real problem is not conversation quality. It is state fidelity.

The paper begins from a familiar design pattern in AI agents. When a task becomes too complex for one model call, developers split the work across multiple agents: one plans, another executes, another checks, another summarizes, and so on. This looks reasonable. It also creates new coordination surfaces.

Scientific workflows are especially hostile to this style of improvisation because the important objects are not paragraphs. They are molecular geometries, basis sets, charges, multiplicities, force-field outputs, wavefunction-like intermediate objects, spectra, CIF files, topology assignments, and large numerical arrays. These objects are expensive to recompute and risky to translate repeatedly through free-form language.

El Agente Gráfico, or Gráfico, changes the unit of coordination. Instead of asking an LLM to keep the workflow state alive through chat, it represents scientific state as typed Python objects, moves computation through execution graphs, and persists important objects into a knowledge graph through an object-graph mapper.

The difference is not cosmetic. It changes where intelligence is allowed to be vague and where the system must be strict.

The mechanism-first reading matters because the paper’s benchmark results are not magic dust sprinkled on a single-agent system. The numbers follow from a design choice: keep the LLM in charge of high-level decisions, but stop forcing it to impersonate a database, workflow engine, and scientific object store at the same time.

A model can reason. It should not be asked to remember a large molecular state by reading its own previous chat messages. That is not autonomy. That is clerical abuse.

Gráfico turns workflows into typed state transformations

The central mechanism is the execution graph.

In the GPU4PySCF workflow used in the paper, tasks such as single-point calculation, geometry optimization, frequency calculation, imaginary-frequency removal, molecular analysis, and TDDFT are represented as graph nodes. Edges define which transitions are allowed. Some transitions can be conditional or cyclic, such as returning to a repair step when an imaginary frequency is detected.

This is important because it narrows the LLM’s job. The model does not invent the entire workflow from scratch every time. It selects among valid next steps and supplies schema-compliant inputs. A routing controller, itself an LLM call, operates inside this graph, but its output is constrained by the available successor nodes and their schemas.

That gives the system a useful compromise:

• the LLM still interprets user intent and chooses paths;
• the graph prevents illegal workflow transitions;
• typed schemas prevent many bad tool inputs before execution;
• intermediate scientific state remains outside the fragile conversational context.

This is not “no-code science by chatbot.” It is closer to an agent operating a typed scientific runtime. Less glamorous. Much less likely to wander into a swamp wearing a lab coat.

ConceptualAtoms is the quiet abstraction doing the heavy lifting

A second mechanism is the typed abstraction layer around scientific objects.

The paper uses ConceptualAtoms as a unified in-memory interface for molecular and periodic systems. It supports checks such as charge and multiplicity validation, and allows different tools to exchange molecular state without repeatedly converting everything into text or files. Package-specific input/output classes compose with this shared abstraction, so a workflow can move from conformer sampling to electronic-structure calculations while maintaining direct Python object references.

This is where the architecture becomes more general than chemistry.

Many enterprise AI systems fail in the same way, only with less dramatic terminology. A sales agent loses account state. A compliance agent confuses policy versions. A finance agent mixes assumptions from two model runs. A data agent treats a dataframe summary as if it were the dataframe. Different domain, same sin: using language as the container for operational state.

Gráfico’s answer is not “never use language.” It is sharper: use language for intent, explanation, and controlled decisions; use typed state for the objects that determine correctness.

That distinction is the article’s main business lesson.

The knowledge graph is not decoration. It is memory with identifiers.

The object-graph mapper serializes Python objects into a knowledge graph with unique identifiers. This lets the agent retrieve previous results, avoid repeated serialization or reinitialization of heavy data, and query relationships among persisted objects.

The paper’s MOF example makes this practical. The agent processes experimental structures, decomposes CIF files into topology, metal nodes, and linkers, searches combinations in the knowledge graph, builds hypothetical MOFs, optimizes them, and analyzes porosity. It then uses cross-session persistence: in a new session, the agent queries previously investigated structures with a given metal node, groups them by topology, and summarizes pore-size versus surface-area trade-offs.

This is the part that should make enterprise architects pause.

Most current “AI memory” discussions are still too close to chat recall: remember the user’s preference, summarize the previous conversation, retrieve a few documents. Useful, but limited. Gráfico’s memory is closer to an operational graph: objects, relations, provenance, and reusable identifiers.

For business workflows, that distinction maps cleanly:

The inference for business is straightforward but bounded. If a process has structured objects, repeatable tool calls, clear validation rules, and a need for audit trails, then a typed context architecture can reduce cost and improve reliability. If the process is exploratory brainstorming with weak state requirements, the same architecture may be overkill. Not every coffee chat needs a knowledge graph. Some do, but those are usually the ones already taking themselves too seriously.

The benchmark shows efficiency, not just accuracy

The paper evaluates Gráfico on six university-level quantum chemistry exercises from the earlier El Agente Q benchmark, each with two difficulty levels and repeated ten times, giving 120 runs per evaluated LLM. The tasks include organic and inorganic molecule analysis, hydrogen-abstraction energetics, cycloalkane ring strain, pKa prediction for halogenated acetic acids, and TDDFT excited-state energies.

The evaluation design matters because agent outputs are not just final answers. The authors use a dual evaluation framework: deterministic numerical checks for computational correctness, and an LLM-as-judge for semantic task adherence, reasoning, and reporting quality. They also track tokens, cost, API requests, context-window saturation, retry cost, and carryover tokens.

The headline comparison is against the prior multi-agent El Agente Q system.

The paper reports a cost drop from $4.67 to as low as $0.17 with gpt-5, roughly a 96% reduction, and a runtime reduction from 1,827 seconds to roughly 200–300 seconds. It also reports trace token consumption falling from about 1.6 million to roughly 100k.

Those numbers should be interpreted carefully.

The result is not simply “single agent beats multi-agent.” A bare single agent can still be a mess, and the paper tests that too. The stronger interpretation is: once the workflow is constrained by typed execution graphs and structured state, a single capable agent can avoid much of the communication overhead that multi-agent decomposition creates. The system is not smaller because the task is simpler. It is smaller because the architecture stops translating state through conversational bureaucracy.

This is a useful anti-pattern to remember: multi-agent systems can become a meeting culture for software. Everyone talks. The work slows down. Then someone proposes another coordinator.

The bare LLM comparison is a warning about tool improvisation

The paper includes a lightweight “bare” LLM agent equipped only with web search and code execution. This is not the main benchmark; it is better read as a diagnostic comparison. Its purpose is to ask whether a general-purpose LLM with tools can bootstrap the same kind of scientific workflow without Gráfico’s typed structure.

The answer is: sometimes it can attempt the work, but it fails important scientific checks and burns far more context.

On the inorganic task, the bare agent ran molecule setup and GPU4PySCF calculations, but made point-group and population-analysis errors, omitted frequency and imaginary-mode handling, and produced the wrong ClF$_3$ geometry: trigonal planar instead of T-shaped. On the pKa task, it mixed up solvation and deprotonation energy handling, failed to check imaginary frequencies, and produced a pKa of about -5.0, outside the accepted rubric range.

The efficiency gap was also severe. The bare agent consumed roughly 40 minutes and 650k tokens for the inorganic task, and roughly 16 minutes and 450k tokens for the pKa task. Gráfico with gpt-5 used about 3 minutes and 25k tokens for the inorganic task, and about 5 minutes and 122k tokens for the pKa task.

This comparison should not be oversold. The paper notes that repeated automatic evaluation of the bare agent was infeasible because of stochasticity. So this is not a full statistical benchmark.

But as an implementation lesson, it is valuable. General code execution gives the agent flexibility. It also transfers the verification burden back to experts. In scientific or regulated settings, that means the human still has to audit the generated code and the result. The system has moved effort from “design the workflow” to “inspect the mess after execution.” This is not always progress. Sometimes it is just a different invoice.

The extension cases show what the abstraction can carry

After the quantum chemistry benchmark, the paper extends Gráfico to two larger workflow classes: Boltzmann-weighted spectroscopy in solution and MOF design.

These are not the same kind of evidence as the main benchmark. They are exploratory extensions, showing that the abstraction can carry more than one hard-coded benchmark. That distinction matters.

The spectroscopy case coordinates conformer sampling, solvation modelling, TDDFT calculations, deduplication, Boltzmann weighting, and spectral construction. In implicit solvation, Gráfico compares water and n-heptane for a merocyanine compound. In explicit solvation, it compares gas-phase and explicitly solvated 2,3-epoxybutanol with a water cluster, producing a solvent-induced red shift of the dominant absorption band.

The MOF case is more graph-native. The agent acquires structures, decomposes them semantically into topology and building blocks, searches combinations in a knowledge graph, constructs candidate MOFs, optimizes geometries using GPU-accelerated machine-learned interatomic potentials, and computes porosity. It builds and analyzes 17 hypothetical MOFs, then uses the persisted knowledge graph in a later session to query trade-offs.

The important point is not that the agent “did MOF design.” The important point is that the same typed state and persistence architecture supports a workflow where earlier outputs become later search space. That is a different level of memory from a chat summary.

This is a better way to read the paper than treating every experiment as the same kind of claim. The benchmark supports the strongest performance claim. The extensions support architectural generality. The bare-agent case explains why unstructured flexibility is not enough.

The business value is cheaper diagnosis, not just cheaper execution

For Cognaptus readers, the tempting summary is: “Use typed graphs to save tokens.” That is true, but too narrow.

The more valuable business implication is diagnostic clarity. A typed graph system can tell you where a process failed: invalid input, illegal transition, tool error, convergence failure, missing artifact, schema mismatch, resource conflict, or weak reasoning. A chatty agent often gives you a transcript and asks you to become a forensic linguist. That may be fun once. It is not a management system.

The business relevance is strongest in workflows with five properties:

1. \ast\astStructured operational objects.\ast\ast The work revolves around entities that can be represented as typed objects: invoices, claims, contracts, assets, molecules, machines, customer accounts, or model portfolios.

2. \ast\astRepeatable tool chains.\ast\ast The system calls tools in known families of steps, even if the exact path varies.

3. \ast\astValidation rules.\ast\ast There are deterministic checks or expert-defined rubrics that can catch invalid states before damage accumulates.

4. \ast\astAudit requirements.\ast\ast Users need provenance, versioning, execution logs, and defensible outputs.

5. \ast\astExpensive context drift.\ast\ast Errors caused by lost or distorted state are materially costly.

That describes many serious AI automation opportunities: R&D workflows, engineering simulation, compliance review, financial risk pipelines, insurance claim processing, procurement checks, regulatory reporting, and data-quality remediation.

It does not describe every chatbot. Good. The world has enough over-engineered chatbots wearing enterprise badges.

What Cognaptus would infer for enterprise architecture

The paper directly shows results in computational chemistry and materials workflows. It does not prove that every enterprise AI system should copy Gráfico’s stack. Still, it offers a transferable architecture pattern.

A business version would look like this:

User intent
   ↓
Main agent interprets goal
   ↓
Typed workflow graph selects admissible step
   ↓
Tool executes against typed business object
   ↓
Validation checks state and output
   ↓
Object store / knowledge graph persists result
   ↓
Agent explains, queries, or continues

The design principle is simple: separate conversational control from operational state.

For implementation, this suggests several concrete moves:

The quiet lesson is that “agent reliability” is partly a software architecture problem. Not a vibe. Not a prompt template. Not another panel discussion about reasoning.

Boundaries: where the paper should not be stretched

There are several boundaries to keep intact.

First, the empirical evidence is from scientific computing, especially computational chemistry and materials workflows. These domains have structured objects, established tools, and meaningful validation checks. That is exactly why the architecture works well. A business process with ambiguous goals, constantly shifting rules, and no reliable validation layer will not automatically benefit from typed execution graphs.

Second, Gráfico still depends on substantial expert engineering. The paper’s methods describe customized infrastructure, Pydantic-based schemas, GPU scheduling, OGM integration, and several domain tools and forks. This is not a weekend prompt hack. It is a systems project.

Third, the current design assumes a single-agent, single-session context over a persistent knowledge graph. The paper itself notes future challenges for distributed and long-horizon operation: synchronizing shared state, managing divergent knowledge graphs, versioning ontology changes, and supporting richer context graphs over time.

Fourth, evaluation remains hard. The authors note that benchmark construction and ontology definitions are laborious, and that probabilistic agents can discover solution paths outside manually specified rubrics. This is a very real problem for enterprise AI as well. If workflows evolve, tests and schemas must evolve with them. Unit tests do not remain wise by aging quietly in a repository.

Finally, structured execution can reduce flexibility. That is not a flaw; it is the price of reliability. The right design may use unconstrained agents for prototyping and typed graph systems for production. The paper’s own bare-agent comparison supports this split: use flexible agents to explore, but do not confuse exploration with dependable execution.

The misconception to retire: complexity does not always require more agents

The strongest misconception addressed by this paper is the belief that complex AI work naturally requires a committee of agents.

Sometimes it does. But the paper shows a different failure mode. Multi-agent decomposition can reduce context load, but it can also introduce coordination overhead, duplicated communication, ambiguous state ownership, and verification problems. If the underlying issue is that execution state is untyped and ephemeral, adding more agents may simply distribute the confusion.

Gráfico’s alternative is not “one agent to rule them all.” It is “one agent operating inside a better execution substrate.”

That is the distinction business teams should carry forward. The question is not:

How many agents should we deploy?

The better question is:

Which parts of the workflow require language reasoning, and which parts require typed state, validated transitions, persistent memory, and deterministic checks?

Once that question is asked, many agent architecture debates become less mystical. Conveniently, they also become less marketable as magic. Tragic, but survivable.

Conclusion: chat is the interface; typed context is the system

El Agente Gráfico is valuable because it moves the conversation from agent personality to agent infrastructure.

It shows that a scientific agent can become faster, cheaper, and more reliable when the workflow stops treating text as the place where state lives. Execution graphs constrain what can happen next. Typed objects preserve scientific meaning. Knowledge graphs make memory persistent and queryable. Evaluators separate numerical correctness from fluent reporting.

For business AI, the translation is clear: serious automation needs context engineering, not just prompt engineering. The agent may still talk like a helpful assistant. Underneath, it should behave more like a typed workflow engine with memory, provenance, and validation.

The interface can remain conversational. The system should not be.

\ast\astCognaptus: Automate the Present, Incubate the Future.\ast\ast