Methodologies and practices for building AI systems: approaches such as RAG, prompt engineering, agent design patterns and evaluation. The “how” of AI development.

Adopt

Mature, well-supported approaches ready for production use.

Classical ML

Classical machine learning covers approaches such as random forests, gradient boosting (XGBoost, LightGBM), linear and logistic regression and support vector machines. For structured data problems they strike the best balance of explainability and efficiency, routinely outperforming more complex approaches on tabular data while training faster and costing less to run.

The returns depend on quality training data and staff with the right expertise. LLM-based solutions have opened AI to organisations without data science teams, but classical ML still demands specialised knowledge in feature engineering and model selection. If you have those capabilities, these methods work well even on smaller enterprise datasets, matching or exceeding more complex approaches while staying easier to interpret and maintain.

RAG

Retrieval-Augmented Generation (RAG) combines search and text generation to ground responses in real data and reduce confabulation. It’s valuable where accuracy and traceability are the priority, such as customer service or compliance. Evaluate your document processing and embedding strategy, and note that RAG introduces an indirect prompt-injection surface: adversarial content in any retrieved document reaches the prompt through the retrieval step, so apply retrieval access controls and track provenance on ingested documents. We’re watching techniques such as Self-RAG, which prompts the model to gather more evidence before answering and shows reductions in so-called hallucinations.

RAG is a fundamental technique for grounding agents, but it’s not the best solution in every case. For visually complex documents, the usual parse-OCR-chunk-embed route mangles tables, forms and scanned pages. One emerging solution is late-interaction visual retrieval: the ColPali and ColQwen family instead embeds the page image at patch level and matches with MaxSim so layout survives. The cost is a much larger index, but this may be worth the trade-off if your corpus is scans rather than clean prose, and index sizes can be reduced with compression such as MUVERA. RAG isn’t always the answer for plain text either. For coding agents, Anthropic’s Claude Code team found that direct agentic search, e.g. grep, glob and reading files, beats a pre-built embedding index.

LLM-as-a-judge

LLM-as-a-judge uses one model to score another’s output, and it’s become a practical way to evaluate AI systems. Today’s strongest models give nuanced, multidimensional critique that simpler methods can’t match, except on very constrained metrics such as exact match or BLEU scores.

The technique is widely adopted in both offline and online evaluation. Offline, it scales far better than human assessment, allowing teams to test thousands of outputs quickly. Online, a judge can score output in real time, letting you adjust the workflow on the quality it reports.

Research demonstrates that frontier models provide judgements correlating strongly with human preferences across many evaluation dimensions. We recommend using a different LLM as the judge than the one being evaluated, and viewing this as an augmentation to human evaluation rather than a replacement. The strongest LLMs can identify nuanced issues in reasoning and factuality that would otherwise require substantial human review time.

BERT variants

Bidirectional Encoder Representations from Transformers (BERT) changed NLP by processing words in relation to their whole context rather than sequentially, and the family keeps evolving, with ModernBERT the latest iteration. Where generative models produce text, BERT-style encoders are optimised for understanding tasks such as classification and sentiment analysis, and they remain the basis for the semantic embeddings RAG uses.

We recommend DeBERTa for new NLP projects, for its disentangled attention; DistilBERT is smaller and faster where latency is tight; and domain-specific variants exist for biomedical (BioBERT) and financial text (FinBERT).

Few-shot prompting

Few-shot prompting gives a model a handful of examples to steer its responses, and it’s worked consistently across large language models. The advice is shifting, though.

As models grow more capable, interactive multi-turn approaches are gaining favour: instead of supplying examples upfront, practitioners prompt the model to ask clarifying questions and iterate toward a solution. The pattern often produces better results, particularly in agentic workflows where the model can refine its approach.

Reasoning models shift the balance further. OpenAI and Anthropic both advise defaulting to zero-shot for them and stating explicit success criteria the model can check its output against, rather than supplying worked examples which can even degrade reasoning-model performance. Persona framing has weakened too: research finds that “act as an expert” prompts do not reliably improve factual accuracy, though they still help steer tone and format.

Few-shot prompting retains an important role in non-interactive contexts. System prompts and automated pipelines do not afford clarifying dialogue, and well-chosen examples remain the most effective way to establish output format and domain conventions. We typically see diminishing returns beyond 3-5 examples, with token consumption as the main trade-off.

Agentic tool use

Agentic tool use lets an assistant act as well as talk: edit files, run tests, execute shell commands and perform web searches. Coding assistants that can do this are far more useful than those limited to conversation, which is why we’ve moved the technique to Adopt for local, sandboxed environments.

The ecosystem has matured to support this. Standards such as MCP and OpenAI’s Function Calling provide reliable integration patterns, while improved observability tooling lets teams monitor what agents are doing. The Development Containers specification makes it straightforward to isolate agent execution.

The risk grows once an application accepts external user input, because prompt injection is still unsolved. An agent that safely edits files for a developer becomes a liability when it processes untrusted input. So adopt it for local developer tooling and internal workflows, but proceed with great caution for customer-facing systems, treating each tool permission as a potential attack vector.

Spec-driven development

A natural-language prompt has ambiguities the model resolves silently, so the code an agent returns is sometimes not the code you thought you asked for. Spec-driven development is the industry’s response: a written specification becomes the contract the agent builds against, and the plan-implement-verify loop in agentic IDEs works from that spec. Tools such as GitHub Spec Kit and Amazon’s Kiro have made the practice mainstream, and the discipline is worth adopting: a reviewed spec gives the agent a clear target, and gives you something to check the result against.

A specification written in prose, though, only moves the ambiguity from the prompt into the spec. Markdown, and even structured forms like EARS or Gherkin, still rely on the model to interpret the words. Nothing stops two requirements contradicting each other, and nothing checks that the spec is consistent before the agent builds on it.

We are following the rising popularity of formal specification languages, though the field is young and adoption is still limited. Because a formal specification is machine-readable, you can test it for contradictions and mutually exclusive requirements before any code is written. That doesn’t make the spec correct: even a consistent one can describe behaviour you didn’t actually want.

The case is stronger still when the specification is durable, something you maintain alongside the code as it changes rather than write once and discard. A formal language with well-defined semantics is much easier to update than prose, where each edit can let ambiguity back in. Our own Allium is one such language: it gives the agent an unambiguous reference, and it flags conflicting requirements within the spec. For regulated teams, who must show their requirements are consistent and their code meets them, it is worth investing in now.

Claude Skills

Claude Skills are self-contained folders, a SKILL.md of instructions with optional scripts and reference files. They package a procedure the assistant loads on demand, so you don’t re-explain or paste it in each session. Our teams use them daily for drafting proposals, structured debugging, commit messages and PR descriptions. The format now works across several coding assistants, so it doesn’t lock you to one vendor.

For many jobs a Skill is simpler than an MCP server, which needs a running server and a protocol to maintain. A Skill has neither, so it fits best when the work stays inside your own project. Use MCP when the assistant needs to reach a running service beyond it.

An installed Skill can run code, with the usual supply-chain and data-exfiltration risks. The exposure depends on the host: in Claude Code a Skill has full access to the local machine and network, while the API runs it in a sandboxed container with no network by default. Treat a third-party Skill like any other dependency: review it before you install it, and prefer first-party or self-authored ones. Keep the agent’s access tight while one runs.

We place Skills in Adopt because the one caveat, running code you didn’t write, is the same supply-chain risk as any other dependency, kept in check by the review and least-privilege habits above.

Trial

Promising approaches with growing adoption, worth exploring for specific use cases.

Cross-encoder reranking

Cross-encoder reranking enhances AI search and chat systems by examining initial search results more carefully. While embedding search is fast and good at finding broadly relevant content, cross-encoder reranking picks up subtle relevance signals by examining the query and potential results together.

Most teams use a two-step process: embedding search finds 50-100 potentially relevant items, then cross-encoder reranking sorts these candidates to surface the most relevant. The technique often reduces confabulations in downstream LLM responses by ensuring higher quality context selection. Implementation has become straightforward with libraries such as sentence-transformers providing ready-to-use models. Teams should be mindful of the additional latency and may need to tune the number of candidates based on performance requirements.

Ontologies for AI grounding

An ontology is an agreed, explicit model of the entities in your domain and how they relate. An LLM already has a rich, learned sense of those concepts from training, but that understanding is implicit and outside your control: you can’t inspect it or make it match the definitions your business and regulators rely on. Grounding retrieval and agent output in an ontology gives you definitions you set and can audit, and lets the system follow relationships through a knowledge graph to answer questions that plain RAG can’t.

Ontology work usually fails in one of two ways: a formal route that pursues completeness in OWL and never ships, or an ad hoc one that starts as a spreadsheet and grows unmaintainable. Start small and formalise only where you need it, and the tooling is mature. Graph databases such as Neo4j store the model, and LinkML lets you define it in YAML without deep ontology expertise. Begin with one painful, high-value domain, not the whole organisation.

If you find ontologies too constraining, semantic spacetime classifies relationships by the role they play rather than fixing them in a schema. We’re watching this direction.

See also: LinkML, Neurosymbolic AI, Prolog.

Model distillation & synthetic data

Model distillation involves training a smaller, more efficient model to mimic a larger one. A common pattern uses LLMs to generate synthetic training data for the smaller model: the large LLM acts as a “teacher”, creating diverse examples that help the “student” learn desired behaviour. This makes AI deployment more practical for edge devices or resource-constrained environments.

We’re keeping it in Trial because the process requires considerable expertise. Teams need to validate the quality of generated training data and ensure the distilled model maintains acceptable performance. There is ongoing debate about amplification of biases through this approach.

Check the licence of models used for distillation. Llama forbids using its output to train other models.

Structured RAG

Structured RAG extends basic RAG by organising retrieved knowledge as graphs, schemas or typed records rather than flat text chunks. Microsoft’s GraphRAG uses an LLM to build a knowledge graph from source documents during indexing, then queries that graph at retrieval time. This addresses a weakness in standard RAG: questions requiring synthesis across many documents, not a single passage.

GraphRAG has matured since our last radar. LazyGraphRAG reduced indexing costs to a fraction of the original, removing the biggest barrier to adoption. Neo4j provides examples combining graph-based retrieval with LLM generation.

The trade-off remains upfront investment. Graph-based indexing requires more compute and design than vector-based RAG, and the knowledge graph must be maintained as source documents change. If your queries are primarily about finding relevant passages, standard RAG with cross-encoder reranking may suffice. If they do require reasoning across documents, structured approaches justify their cost.

Orchestrator-worker agents

When a task is too big for one agent, or breaks into independent parts, you can spread it across several agents. In the orchestrator-worker pattern, one orchestrator drives the overall task, delegating self-contained subtasks to workers, each with its own context window, and gathering their results. Anthropic’s multi-agent research describes this hierarchy, now built into tools like Claude Code’s subagents.

Only one agent should make changes. Route decisions and edits through a single writer and have the others only read and report, because several agents acting in parallel make conflicting changes that someone has to unpick, which is the core of Cognition’s case against multi-agent systems. Keeping to one writer also limits a security risk. A worker that reads external data can pick up a prompt injection, so it shouldn’t be acting as well: when workers only read and report, their output can be treated as untrusted, and the single writer decides what to act on.

It’s expensive, because each worker runs its own context and the token cost multiplies, and is a poor fit for tightly interdependent work like writing code, where the parts can’t be cleanly separated. The pattern works best on tasks that split into independent pieces, such as parallel research or a breadth-first search across a large codebase.

Evals as a release gate

An AI system has no compiler to catch a regression. A reworded prompt, a model upgrade or a new tool can make the output worse, and often the first signal is rising user complaints. The defence teams have settled on is to treat evaluations as regression tests: score a fixed set of cases on every change and block release when a score drops below its threshold or the last known-good baseline. As Simon Willison puts it, evals are regression tests for non-deterministic systems.

What you gate on depends on the system: task accuracy against a labelled set, cost, latency and jailbreak resistance for most, with agents also checked on whether they chose the right tool and kept to the plan, and retrieval traced back to source. Where a judgement is too nuanced for a simple assertion, LLM-as-a-judge does the work. Promptfoo, DeepEval and Langfuse all run these gates in CI.

We put it in Trial because the gate pays for itself wherever a regression would be costly in production, and for regulated teams it gives model risk management an auditable quality bar. Whether to write the evals first, test-driven style, is contested: Hamel Husain argues for writing evaluators against the failures you’ve already seen rather than ones you imagine up front. Begin with the few cases you know are critical and let the suite grow from the incidents you hit.

Harness engineering

An agent is a model plus a harness, the code around the model that assembles its context, manages its tools, runs its loop, keeps its memory and checks its work. As frontier models converge, the harness increasingly decides whether an agent is reliable: a capable model flails in a poor harness, and a modest one does useful work in a good one.

Much of the craft is removing things and adding structure. When Vercel cut most of an agent’s tools, accuracy rose: a smaller toolset gives it less room to go wrong. The rest is choosing the right loop, setting a stop condition the model can’t just declare met, and resetting context on long jobs so quality doesn’t decay. You don’t have to write all this yourself: the Claude Agent SDK and OpenAI Agents SDK give you a ready loop, tool handling and context management.

The harness is also the control point for security and audit. A leaner toolset is a smaller attack surface, and least-privilege scoping limits the damage from a prompt injection; tool scope, data provenance and a captured trace all live here, which is what model risk management needs. We put harness engineering in Trial: the vocabulary is only months old and the tooling and measurement still settling, but the practices pay off today and we use them ourselves. Treat the harness, not the model, as the thing you’re building.

Context engineering

A long-running agent rarely fails by running out of context window; it fails because the window fills with noise and, as tokens climb, recall and judgement fall away, the effect Anthropic calls context rot. Deciding what stays, and what is summarised, offloaded or dropped, is now a discipline of its own.

It sits next to harness engineering: the harness is the scaffolding around the agent, context engineering is the token budget within a single run. A few techniques help: compaction summarises near the limit and restarts; structured note-taking offloads state to a file; sub-agent isolation hands a subtask a clean window; and tool-result clearing replaces spent outputs with placeholders. Anthropic now exposes compaction, tool-result clearing and a memory tool as API primitives.

For regulated teams, compaction keeps a run going by discarding detail: it preserves the high-level thread, but specific figures and the step-by-step trail can be lost, with nothing in the summary to show it. If an agent’s reasoning has to be reconstructed for model risk management or audit, keep the raw trace. We place context engineering in Trial: the primitives are young and in beta, and the patterns for compacting rather than offloading are unsettled, but the problem is universal for anyone running agents past one window, and the mitigations exist today.

AI content provenance

Marking AI-generated content is now a legal requirement. Under Article 50 of the EU AI Act, transparency duties apply from 2 August 2026: a system generating synthetic audio, images, video or text must mark its output in machine-readable form, a chatbot must tell users they’re talking to a machine, and text published to inform the public must be labelled. The duty falls on providers and deployers, and a breach sits in the middle penalty tier, up to €15M or 3% of global turnover.

The Act doesn’t say which technology to use. The European Commission’s voluntary Code of Practice points to two layers: signed metadata, and invisible watermarking for when it’s lost. In practice the metadata layer means C2PA Content Credentials, the signed-provenance standard backed by Adobe, Microsoft, OpenAI and the BBC.

We place this in Trial because the legal driver is live and the tooling is usable today, but neither layer is dependable on its own. C2PA metadata is easily stripped: a screenshot or re-encode breaks the chain, and it rarely survives across platforms. Watermarks survive edits better but remain imperfect; Google’s SynthID is probabilistic and removable, and 2026 research has stripped and forged such marks. Check each pipeline on its own terms rather than assuming one mechanism meets the obligation.

AGENTS.md and steering files

AGENTS.md is a plain markdown file that tells a coding agent how to work in a repository: how to build and test, the target architecture and conventions to follow, and the things to leave alone. It began as an OpenAI Codex convention and is now a vendor-neutral standard stewarded by the Agentic AI Foundation under the Linux Foundation. Cursor, Codex, Gemini CLI and Copilot read it natively; Claude Code only reads it as a fallback when a project has no CLAUDE.md.

It’s part of a wider practice of project-level steering: keeping the context an agent needs in version-controlled files, not an isolated prompt. Larger projects tend to split these by concern (product, architecture, code style) and reference them from the root file. These files must be correct: if an agent generates the first versions, check them closely, since errors hamper every future session.

Adoption is broad and the cost of starting is low, but we place it in Trial because conventions for structuring and sharing them across teams are still forming. It pairs naturally with harness engineering and spec-driven development, which supply the intent behind these files.

Assess

Emerging or specialised approaches that merit evaluation for specific use cases.

Neurosymbolic AI

Neurosymbolic AI combines neural networks with symbolic reasoning to address fundamental limitations of pure LLM approaches. Neural networks excel at pattern recognition and handling ambiguity, while symbolic AI provides logical reasoning and explainable inference. LLMs understand natural language well but cannot guarantee rule compliance or explain their reasoning in auditable ways.

Fundamentally, this is an architectural problem. LLMs operate through probabilistic pattern matching over language, not causal modelling. As Mark Burgess argues in his work on semantic spacetime, language models “paraphrase intentional knowledge” rather than tracing actual causal chains. Precise answers to precise questions require systems that explicitly encode what causes what.

The case is strongest in regulated sectors. Regulatory rules are non-negotiable constraints, not suggestions a model can approximate. Risk models need to know what entities are and how they relate, and compliance requires explainable decision trails. Similar pressures apply across financial services, healthcare and insurance.

Implementations range from lightweight to sophisticated. On the simpler end, teams constrain LLM outputs to ontology terms or use knowledge graphs to ground RAG retrieval. More advanced implementations use symbolic reasoning engines to validate LLM-generated conclusions. Renewed interest in Prolog reflects exploration of logic programming alongside LLMs.

We place Neurosymbolic AI in Assess because production patterns are still emerging, but teams in regulated sectors should be experimenting now.

World models

World models sit in the Assess ring as an emerging alternative to pure language model architectures for tasks requiring causal reasoning and planning. Where LLMs predict the next token based on statistical patterns in text, world models build internal representations of how environments behave, enabling systems to simulate outcomes before acting.

The field is developing along several paths. Yann LeCun’s Joint Embedding Predictive Architecture (JEPA) learns by predicting missing information in an abstract embedding space rather than reconstructing raw pixels or tokens. Meta’s V-JEPA and VL-JEPA extend this to video and vision-language tasks with far fewer parameters than autoregressive alternatives. Karl Friston’s active inference framework, implemented by Verses AI in their AXIOM system, takes a different approach rooted in how biological systems model their environments. Rather than chasing reward signals, active inference agents build generative models and act to minimise prediction error, with Verses reporting 60% performance improvement using only 3% of comparable deep learning compute. Generative world models form a third strand, with NVIDIA Cosmos and Google DeepMind’s Genie 3 creating physically plausible simulated environments for training robots and autonomous systems.

For financial services, MarS from Microsoft Research demonstrates the pattern applied to market simulation, generating realistic interactive market scenarios for forecasting and anomaly detection without real capital at risk. The paper was accepted at ICLR 2025.

The enterprise value: these approaches offer causal modelling rather than statistical pattern matching. An LLM asked “what happens if I do X?” can only paraphrase similar scenarios from its training data. A world model can simulate the consequences. For teams wanting to experiment, Meta’s V-JEPA 2 and NVIDIA Cosmos models are available on HuggingFace under permissive licences.

LLM reproducibility

Large language models are non-deterministic even at temperature zero, which is a problem for regulated industries where Model Risk Management frameworks require reproducible, auditable decision-making. Banking regulations such as OCC/SR 11-7 assume a level of model stability that generative AI doesn’t provide.

The cause runs deeper than floating-point arithmetic. Research shows that batch-dependent kernel operations make outputs vary with server load, not input alone. Smaller open weight models on controlled infrastructure tend to achieve more reproducible outputs than larger models served via shared APIs. Where stochastic behaviour is acceptable, the variation must be well-characterised so it can be explained to regulators as a designed property rather than an infrastructure artefact. Prompts and model versions should be treated as versioned code with change control and rollback procedures.

For teams requiring determinism from larger models, SGLang now offers deterministic inference building on batch-invariant operators, with the underlying research selected for oral presentation at NeurIPS 2025. Teams subject to MRM requirements should be actively evaluating their options now.

See also: Neurosymbolic AI, LLM-as-a-judge.

Hypothetical document embeddings (HyDE)

HyDE (Hypothetical Document Embeddings) addresses a common problem in search systems: poor performance when searching content that differs from training data. HyDE asks a large language model to imagine what an ideal document answering the query might look like, bridging the gap between how users ask questions and how information is written.

The system creates several hypothetical documents, converts them into embeddings and blends them together. This averaged representation finds real documents that are mathematically similar, often leading to more relevant results than traditional methods. The approach is particularly effective within RAG systems where accurate retrieval is crucial. Teams should evaluate HyDE for cases where high-precision retrieval is needed and the additional latency is acceptable.

GEPA

GEPA (Genetic-Pareto) optimises the prompts in an AI system automatically. It runs the system, reads the traces (reasoning, tool calls, errors) and asks an LLM to diagnose the failures in plain language and propose prompt edits, evolving a Pareto frontier of candidates that do well on different parts of the task. The paper, accepted at ICLR 2026, reports that it outperforms reinforcement-learning tuning while using far fewer rollouts, and improves on the previous best prompt optimiser: MIPROv2.

The appeal for regulated teams is that GEPA works on API-only models without touching weights, and it produces prompts a human can read and review rather than an opaque set of fine-tuned parameters. It depends on a measurable objective, so it fits tasks with a clear evaluation signal better than open-ended generation. We’ve placed GEPA in Assess. It is already available through DSPy as dspy.GEPA, but it is early, and the quality of the optimised prompt depends heavily on the evaluation metric you give it. Teams already investing in prompt optimisation should be trying it now.

Recursive language models

Recursive language models (RLMs), from a team at MIT CSAIL, address a familiar problem: a model’s output degrades as its prompt grows, well before the context window is technically full. An RLM keeps the long context as a variable in a code environment and gives the model only the query, so the whole context never enters the model’s window at once; the model writes code to slice and filter it, calling itself or cheaper sub-models over the parts it needs. Alex Zhang’s write-up reports working over context far larger than any single model’s window this way. It extends the code-execution pattern (CodeAct) with recursive calls, and where orchestrator-worker agents split a task along a plan, an RLM splits the context itself and lets the model decide how.

Because the model writes and runs code over context that’s often untrusted, a malicious document can steer the generated code, so sandbox the REPL with least privilege: no network and no filesystem reach beyond the context variable itself. We place RLMs in Assess. The research is credible and there’s an active open-source implementation, but the results are largely author-reported, the latency is unpredictable and we’ve seen no production use. Try it where context length is the binding constraint.

Purpose-built classifiers

Many of the jobs teams give an LLM are classification tasks: routing a request, detecting intent, scoring a document or deciding whether an action is safe. A model built for one of these answers in milliseconds, costs a fraction of a frontier API call, and returns a label you can act on, often with a calibrated confidence score. Place one in front of an agent to handle the straightforward cases, and the expensive model gets called far less often.

Encoder classifiers have done this work for years. GLiNER and GLiClass classify against arbitrary labels with no task-specific training, run on your own hardware, and come from the same BERT family already in our Adopt ring. A small encoder fine-tuned on a few thousand of your own examples will usually beat a hosted service on cost and latency, and it keeps the data in house.

Most of the interest this quarter is in TypeSafe’s Jev, a proprietary hosted model that returns a calibrated distribution over a fixed set of answers, through its own API or OpenRouter’s experimental decisions endpoint. Independent testing confirms the speed and the price, though the claim that it can’t hallucinate is overstated and its headline benchmarks look stronger than the detailed results. We put the category in Assess: the approach is sound and worth a place in the toolbox, but there’s little reason to use a closed service for work that open encoder models already do on infrastructure you control. Start with the mature open options and treat the hosted newcomers as a convenience, not a default.

Fine-tuning with LoRA

Low-Rank Adaptation (LoRA) fine-tunes a model by training a small set of added parameters and leaving the base weights frozen. That keeps training cheap enough to run on modest hardware and produces a lightweight adapter rather than a full copy of the model, close to the quality of a full fine-tune. It has made customising open-weight models practical for teams without large training budgets.

Tools such as LitGPT and axolotl make the training loop straightforward, but applying LoRA well still takes ML expertise and clean, well-chosen training data. The larger risk is lock-in: a fine-tune ties you to one base model, and models improve quickly enough that a newer general-purpose release can overtake the one you tuned months ago, leaving you to maintain and re-tune it. We place it in Assess rather than Trial, and would reach for it only where the business value clearly outweighs that ongoing cost.

Reinforcement fine-tuning is the other route to a tuned model. LoRA learns from examples; reinforcement fine-tuning learns from a reward: run the model on a task, score the output with a programmable grader or an LLM judge, and apply GRPO-style updates that raise the odds of the behaviour that scored well. Through 2026 it became a common way to turn an off-the-shelf model into a reliable agent for tool-calling and coding, and a tooling layer grew up around it: RL environments packaged as installable Python packages such as Prime Intellect’s verifiers and OpenPipe’s ART, with LLM-as-judge reward shaping such as RULER. It sits in Assess alongside LoRA: for most teams reward design and environment construction are still specialist work, the failure mode is reward hacking rather than the behaviour you were after, and an RL-tuned model is harder to account for under model risk management than a prompted one, because its behaviour lives in shifted weights rather than an inspectable prompt.

Physical AI and robotics foundation models

Physical AI represents the convergence of foundation model capabilities with robotics. Where traditional robotics relied on brittle, task-specific programming, robotics foundation models enable machines to generalise across tasks and adapt to novel situations.

The technical breakthrough is Vision-Language-Action (VLA) models, which extend vision-language models to include physical action outputs. NVIDIA’s Isaac GR00T N1 represents the first open humanoid robot foundation model, using a dual-system architecture that separates deliberate planning from rapid reactive control. Google’s Gemini Robotics is advancing similar capabilities. World Foundation Models complement these by enabling simulation-based training: NVIDIA Cosmos generates physically plausible synthetic environments that can train robots on scenarios too dangerous or rare to capture in the real world.

Production deployments remain concentrated in well-resourced organisations. The gap between research demonstrations and reliable industrial deployment is wide. Hardware costs have fallen over the past few years, but perception and control challenges in unstructured environments remain formidable. Organisations with physical AI ambitions should be experimenting, while approaching production timelines with caution.

CaMeL

CaMeL (CApabilities for MachinE Learning) is a defence architecture from Google DeepMind for mitigating prompt injection in agentic systems. Its paper, Defeating Prompt Injections by Design, treats prompt injection structurally rather than through prompt cleverness or red-teaming. The architecture splits responsibilities across two models: a privileged P-model processes only user instructions and emits a program of execution steps, while a quarantined Q-model handles external data but cannot call tools directly. A custom interpreter tracks data provenance, enforcing capability-based security so untrusted data cannot escalate privileges. The implementation is open source.

Prompt injection is the dominant unsolved problem for agentic systems, and it recurs throughout this radar, in MCP, agentic tool use, AI red teaming tools and our Hold placement for OpenClaw. Most defences are statistical, such as filters, classifiers and harnesses. CaMeL is one of the first to make the architecture itself prove that untrusted data can’t reach privileged operations, reducing many attacks on the AgentDojo benchmark to zero.

We place CaMeL in Assess: it addresses prompt injection more rigorously than anything else we have seen, but production patterns have not emerged, users must author security policies, and running two models adds latency and cost. For teams building agentic systems in regulated industries, the paper is required reading.

Agent identity

When an agent acts, whose authority is it acting under? Most production systems cannot answer cleanly. Agents read and write through a shared service account or a long-lived API key, so there is no record of which agent took an action, let alone which human authorised it. Over-permissioned, shared credentials are among the most common and hardest-to-retrofit failures in agent deployments, and they are exactly what least privilege and clear trust boundaries exist to prevent.

The fix reuses established non-human identity practice. Give each agent its own scoped, short-lived credential instead of a shared secret. SPIFFE issues cryptographically attested workload identities on this model, OAuth 2.1 with PKCE covers browser-driven agents, and signed delegation tokens preserve the chain of authority, from the human who triggered the work through each agent that acted on it. Bind every action to that identity, so you can trace who did what and revoke the credential when the agent is retired.

Attention is catching up to the risk. OWASP’s Top 10 for Agentic Applications puts identity and privilege abuse among its leading risks, and NIST opened an AI agent identity and authorisation initiative in early 2026. For regulated teams the driver is sharper still: HIPAA’s unique-user-identification rule, GDPR’s accountability principle and SOX audit trails all assume you can say who did what, which a shared agent account cannot support.

We place this in Assess. The underlying primitives are production-proven outside AI, but the agent-specific patterns and tooling are young and still settling, so experiment now rather than retrofit attribution later.

Hold

Not recommended for new projects; better alternatives exist.

Word2Vec & GloVe

We’ve placed both GloVe (Global Vectors for Word Representation) and Word2Vec (Word to Vector) in the Hold ring of our techniques quadrant. While these word embedding techniques broke new ground when introduced and underpinned many NLP applications, they have been largely superseded by more advanced approaches.

These older embedding techniques, though computationally efficient, lack the contextual understanding that modern transformer-based models provide. Modern large language models and contextual embeddings such as BERT produce more nuanced representations that capture word meaning based on surrounding context, rather than the static embeddings that GloVe and Word2Vec generate. For new projects, we recommend exploring more recent embedding techniques (see “BERT Variants” in our Adopt ring) unless you have very specific constraints around computational resources or model size that make these older approaches necessary.

Zero-shot prompting

Zero-shot prompting, the practice of asking Large Language Models to perform tasks without examples or training, has been a quick way to get started with AI. We recommend against using zero-shot prompts in production without appropriate guardrails and safety measures. We’ve heard of multiple incidents where unprotected prompts led to harmful or inappropriate outputs that exposed organisations to reputational and compliance risk.

Our view is that zero-shot prompting should always be combined with input validation and output filtering. While it can be valuable for prototyping and exploration, moving to few-shot prompting or fine-tuning with careful guardrails is a more robust approach for production systems. The current placement in Hold reflects our concern about organisations rushing to deploy unsafe prompt patterns rather than taking the time to implement proper controls.

Chain of thought (CoT)

Chain of Thought (CoT) sits in Hold. While useful when it emerged, research from Wharton’s Generative AI Labs demonstrates diminishing returns: gains are rarely worth the time cost, and for reasoning models such as o3 and GPT-5.2, CoT prompting can decrease performance since step-by-step reasoning is already internalised at the architecture level.

For non-reasoning models, CoT still shows modest benefits on mathematical and symbolic reasoning tasks, but these are precisely the domains where better alternatives are emerging. Dedicated reasoning models handle them natively, while neurosymbolic architectures offer more reliable solutions by coupling LLMs with explicit reasoning engines.

The frontier of prompt engineering has moved to structuring problems effectively. Frameworks such as the 5 Whys and inversion now offer more value than CoT prompting. Step-by-step reasoning is now handled by the models and architectures rather than the prompts.

AI pull request review

AI now reviews code well. Developers who work effectively with multi-turn conversations can get useful feedback at every level, from syntax issues and architectural patterns to subtle runtime concerns such as race conditions.

We keep AI pull request review in Hold for organisational rather than technical reasons. In addition to finding errors, PR review also shares knowledge: senior developers mentor juniors, and the team keeps track of how the codebase evolves. Teams who delegate review to AI often see a decline in collective code ownership.

We recommend using AI as a first-pass reviewer to catch issues before human review, but preserving the human step as deliberate practice for team alignment and knowledge transfer.

Techniques