Dr Raminderpal Singh

How fred actually runs

Four properties that distinguish fred from “a ReAct agent that calls PubMed.”

Validating the reasoning core

The continuous graph cannot be trusted if the unit reasoning task is not accurate. The current evaluation runs fred’s reasoning core against Claude Opus 4.7 on the same biomedical research questions, head-to-head. fred runs each question three times with citations independently judged; Opus runs each once with web search. A separate Opus chat then reads both sides and produces a qualitative comparison. The point is not that fred “beats Opus” — it is whether fred’s specialized reasoning core produces output that holds up against a frontier general-purpose model when citations can be mechanically checked. Full run logs and comparisons are published openly on projectfred.dev.

Scope disclaimer: the continuous knowledge graph is the target architecture, not what is currently shown publicly. The published evidence validates fred’s reasoning core doing one unit task at a time. The ingest / infer / emit loop that turns those unit outputs into a continuously refined private graph is in active development.

Where agentic engineering fits life sciences R&D, and where it does not

Agentic engineering is the current direction of the software market: coding agents that read the repository and run the commands, hooks that block a rule violation before it lands, and products built as teams of specialist agents that plan, research, write and review one another. For most software that direction is correct. Where the work decomposes into independent pieces and a wrong answer is cheap to check, as in ScienceClaw’s autonomous research pipelines, many agents are the right design.

I also build a different kind of system: decision support for pre-clinical drug discovery, where a human committee makes a contested scientific decision and the software assembles cited evidence for it. Compound Insights and the SIM Framework are that kind of system. On that work I have adopted part of the trend and declined part, and the division follows one question: can every output be traced to its evidence, attributed to the engine version that produced it, and reproduced?

Once the tooling language is removed, agentic engineering is a claim about process. An LLM cannot verify its own output, so quality comes from external verification at gates, a human holding the judgment at those gates, and failures converted into standing controls. I arrived at that process independently and apply it without exception. Every science and governance decision is mine, recorded before it takes effect. Every write passes its gates before I say go. Every prediction is scored, and every miss stays on record with the measurement that produced it. The difference between my method and a coding agent is a single row of the table below: who executes the deterministic layer. The agent runs the commands. I run them.

My environment is one browser tab and one terminal: the Claude.ai app writes the code, I download the file, run the command and paste the result back, and control lives in standing settings and project instructions rather than in the chat. The environment, the three principles behind the gates, the failure patterns I have recorded and the check that catches each one are written up in full on ↗ AI Coding: a practical approach for scientists, with Compound Insights as the worked case study.

That substitution has a cost, and I state it plainly. A coding agent reads the live repository; I work from what I upload, so the model can edit a copy of a file when the live one has moved, and that is my most frequent error class. An agent executes faster than my turn rate, so it exposes new failure classes sooner, and its rules live in hooks that another person could run. Those costs are real. They govern how fast the method finds its own defects and whether it transfers to a second engineer. They do not govern whether the delivered software is correct or whether its outputs can be defended, and on those two the method is equal to current practice or ahead of it.

How I build

What is inside the product

Inside the product the decision is different in kind. The market pattern is an orchestrator with planner, researcher, critic and writer agents passing state between them. Compound Insights and the SIM Framework use one reasoning engine, project fred, pinned to a version and never edited by the application that calls it. Every value carries the prompt version, the run id, the tool calls and the citation state that produced it. Non-determinism lives in one place, where campaigns of repeated runs measure it. The SIM Framework runs that single engine in three fixed roles, constructive, skeptical and arbiter, across repeated runs per claim, and publishes the spread of verdicts across runs instead of resolving it. Neither product emits a go or no-go. A human committee decides.

The published evidence supports the smaller design. The MAST failure taxonomy (Cemri, Pan, Yang et al., NeurIPS 2025) found that multi-agent systems’ gains over single-agent frameworks are often minimal, and located their failures in three places: specification issues, misalignment between agents, and weak verification. A hallucination in one agent becomes a fact for the next. What many-agent designs do well is fan out over independent subtasks. That is speed these products cannot use, because the engine serializes runs by design, and it would be bought with the two properties they exist to provide, attribution and reproducibility.

The test I apply, and the one I suggest you apply

For a biopharma executive evaluating an AI system for R&D, the test is the one I apply to my own work. If the output is a web page or a data pipeline, buy agents and buy speed. If the output is a scientific claim that a scientist will act on, ask four questions. Which version of which engine produced it? Was it replicated? Where did each citation come from? Who decided? A system that cannot answer those questions has produced a plausible answer, and in pre-clinical R&D a plausible wrong answer costs more than a slow right one.

The argument on this page is set out in full, with references, as a positioning paper prepared for arXiv: ↗ Attribute, Never Assert: A Single-Engine, Human-Decided Alternative to Agentic Engineering for Decision Support in Pre-clinical Drug Discovery (PDF preprint, September 23, 2026).

The verdicts in both tables are my assessment against my projects’ own standard (attribute, never assert; no silent failure; measured, not inferred), drawn from the project record and the 2026 literature. They are judgments, not measurements. Sources: ↗ MAST, “Why Do Multi-Agent LLM Systems Fail?” (arXiv 2503.13657); ↗ METR, randomized trial of AI tools for experienced developers (2025).

Engineering discipline meets AI momentum

I'm an AI Engineer with a deep-rooted foundation in systems engineering — trained to understand how complex pieces fit together, where the friction is, what the boundaries between components should be, and what it takes to make something work reliably at scale. That instinct shapes everything I build.

What excites me about this moment is the raw momentum that AI brings. The speed at which ideas can become working software has fundamentally changed. But momentum without structure produces fragile systems, hallucinated outputs, and untestable code.

AI has made Systems Engineering more critical, not less. When AI writes the code, the architect is still accountable. The value a human brings is no longer in the implementation — it is in requirements elicitation, defining module boundaries, and deciding what the system should actually do. Those are systems engineering decisions that no AI agent makes reliably without that discipline enforcing the structure.

I particularly enjoy building software appliances for R&D scientists — purpose-built tools, including project fred, that deliver autonomous, reliable research capabilities. ScienceClaw is the embodiment of this: an autonomous research platform that scientists can actually trust, built on rigorous engineering principles.

That's the thread running through all my work — from teaching scientists to vibe‑code responsibly, to building test‑first workflows that keep AI agents honest, to deploying autonomous research platforms. Two decades inside scientific R&D — understanding how experiments are designed, where data breaks down, what regulators care about, and why adoption stalls — means I build for the constraints that actually exist, not the ones that look good in a pitch deck.

Specification first, and nothing marks its own homework

I don't write the code. Claude writes all of it, and every decision about what gets built stays with me. That division only works if the process supplies the verification that confidence doesn't, so the method rests on three habits.

A specification comes before any code, and an adversarial review comes before the specification is accepted. The spec is drafted, then attacked by a separate prompt written to find fault, then amended. On one Compound Insights specification that pass found eleven defects, five of them structural — a field defined at the wrong granularity, a circular step that depended on a prompt a later step produced — all before a line of code existed. Checking while writing is not a review.

Every change runs as a script with its own guards, not as code pasted into a file. The script states what it expects to find, shows in a dry run exactly what it would change, and aborts if the file isn't what it expected. One aborted correctly on finding four matches where it expected two; the extra two were historical record and had to stay untouched.

Nothing verifies itself. A test written by the same engine it tests will confirm that engine's mistakes. Citations are re-resolved independently, a second model scores answers after being calibrated on deliberately corrupted ones, and results are compared against a stored baseline that refuses to run if the baseline itself has moved. A probe that can't go red is not a probe.

Control lives in standing instructions rather than in the conversation — personalized settings that apply to every chat, and project instructions that govern one application. Both are plain English, and neither is code. When behavior drifts, the fix goes into one of those files, not into the next message.

The whole method is written up in full, with diagrams and the presenter notes for all 23 slides: ↗ AI Coding: a practical approach for scientists — my talk at BAGIM, September 17, 2026, with Compound Insights as the worked case study.