Context Engineering for Multi-Agent Systems
🎞️▶️ In 21st‑century Agentic AI, Natural‑Language‑Programmed LLMs are the execution agents, and the domain‑agnostic dual‑RAG MAS is the environment they operate in. This repository provides a production-ready blueprint for the Agentic Era, allowing you to replace rigid, hard-coded workflows with a dynamic, transparent, observable, and sovereign Context Engine. By building universal, domain-agnostic Multi-Agent Systems through high-level semantic orchestration, you can save thousands of lines of code while maintaining 100% observability.
The GPT-6 Astra Computer Use Capability: The Context Engine now extends from reasoning over context to perceiving and acting within interactive environments through GPT-6 Astra computer use: 🖥️ gpt-6-astra/README.md
The Claude Projects Edition of the Context Engine: The Context Engine with no code at all — nine markdown protocol files running the full Gate 1 → Plan → Gate 2 → Execute → Trace pipeline inside a Claude Project. No Python, no API keys, no vector database, nothing installed: 📋claude_projects/README.md
The NVIDIA NIM NEMOTRON DAG Edition of the Context Engine: The NVIDIA NIM NEMOTRON Edition of the Context Engine adds a real-time DAG planner to the context engine:🐬nim/Universal_DAG_Engine_NIM.ipynb and 🐳☁️ Docker + Railway deployment resources added to the repo.
LangChain Edition of the Context Engine: The LangChain Edition of the Context Engine adds a Context Engine layer on a LangChain substrate:🐬langchain/Universal_Context_Engine_LangChain.ipynb
New Gradio Standalone UI: Chapter10/Universal_Context_Engine_Gradio_UI.ipynb now contains a deployable Gradio web app — live public URL in Colab, one-command deploy to Hugging Face Spaces.
Save thousands of lines of code
Save thousands of lines of code by building universal, domain-agnostic Multi-Agent Systems (MAS) using the ultimate new programming language: 🛰️ View Software Evolution Timeline
🐬 March 14, 2026 update of the January 24, 2026 Release: OpenAI gpt-5.4 implemented in the Universal Context Engine
Sovereign Universal Context Engine: A new Glass Box Context Engine implementation - Chapter10/Universal_Context_Engine.ipynb and Chapter10/Universal_Context_Engine_UI.ipynb- demonstrating domain-agnostic architecture by running cross-domain use cases on the same core.
Token Analytics: engine.py and the Dashboard provide rigorous transparency into token usage (Input, Output, Difference) for cost and verbosity analysis.
The Token & Cost Analytics built into engine.py and the Dashboard implement what is now termed tokenomics in agentic AI systems (Salim et al., MSR 2026; Bergemann et al., ACM EC 2025) — rigorous per-step tracking of token consumption, cost, and verbosity across the full multi-agent pipeline.
🔧 LLM API Updates and Opportunities
For a detailed list of affected notebooks and all changes, see the ➡️ CHANGELOG.md
LLM API update:
Several notebooks have been upgraded to use GPT‑5.1 and also a GPT-6-Astra tutorial(documentation and code) has been added along with the latest OpenAI library standards
These improvements provide better performance, lower reasoning latency, and more reliable handling of structured agent outputs.
This update also includes fixes to the Moderation API, ensuring safer and more robust processing of multi‑agent interactions.
Alternative: Sovereign AI Without External LLM APIs:
If you prefer not to rely on an external LLM API, a full DeepSeek‑R1 Sovereign AI Implementation Guide and the Hardware benchmark notebook (with code) is available:
➡️ DeepSeek‑R1 Sovereign AI Guide
Generative AI is powerful, yet often unpredictable. This guide shows you how to turn that unpredictability into reliability by thinking beyond prompts and approaching AI like an architect. At its core is the Context Engine, a glass-box, multi-agent system you’ll learn to design, strengthen, and apply across real-world scenarios. Written by an AI guru and author of various cutting-edge AI books, this book takes you on a hands-on journey from the foundations of context design to building a fully operational Context Engine. Instead of relying on brittle prompts that give only simple instructions, you’ll begin with semantic blueprints that map goals and roles with precision, then orchestrate specialized agents using the Model Context Protocol (MCP). As the engine evolves, you’ll integrate memory and high-fidelity retrieval with citations, implement safeguards against data poisoning and prompt injection, and enforce moderation to keep outputs aligned with policy. You’ll also harden the system into a resilient architecture, then see it pivot seamlessly across domains, from legal compliance to strategic marketing, proving its domain independence. By the end of this book, you’ll be equipped with the skills needed to engineer an adaptable, verifiable architecture you can repurpose across domains and deploy with confidence.
Computer use can be added to the Context Engine as a new agentic capability — extending the architecture from reasoning about an environment to directly perceiving and acting within it. With GPT-6 Astra, an agent can receive visual state, reason over the environment, select computer actions, and interact with a controlled execution layer. The local harness becomes the bridge between the model and the environment, providing screenshots, action execution, permissions, human oversight, and safety controls.
This creates a new capability layer for the Context Engine:
Context → Reasoning → Perception → Action → Environment → Observation → Context
The capability is deliberately modular. Computer use can sit alongside the Context Engine's existing RAG, memory, MCP, telemetry, governance, and multi-agent components, providing an additional perception-and-action interface for digital environments. The same architectural principle can eventually extend from software environments toward increasingly complex physical environments — making governance, security, human oversight, and sovereign deployment essential parts of the architecture.
✅ The Levels of Efficient Context · ✅ Dual RAG · ✅ Agent Orchestration · ✅ Compliance & Risk
Stop tinkering with prompts. Start engineering context. Most AI implementations fail at scale because they rely on black-box prompting — sending a request into the void and hoping for a coherent reply. Following the success of our January session, Cohort 2 of this hands-on workshop is now open. We move beyond simple instructions to build a Context Engine: a transparent, glass-box architecture where agents don't just guess — they execute a precise, structured plan.
The workshop frames the new software stack as a delegation gradient across four runtimes — from the human running a context engine in their head, through embedded copilots, configured platforms, and engineered systems. Mastery of the underlying tiers is what makes any of them deployable. We close with the question that sits underneath every enterprise AI decision in 2026: which tier does this problem belong in, and what does compliance actually require?
Save thousands of lines of code by building universal, domain-agnostic Multi-Agent Systems (MAS) using the ultimate new programming language: natural language, engineered as context.
🧭 The Tiers of Context Engines — Tier 3 → Tier 2 → Tier 1.5 → Tier 1
⚖️ Compliance & Risk Management — GDPR · HIPAA · SOC 2 · ISO · FedRAMP
This recorded session walks through the entire stack behind the sentence: “In 21st‑century Agentic AI, Natural‑Language‑Programmed LLMs are the agents, and the domain‑agnostic dual‑RAG MAS is the environment they operate in.” The deep dive unpacks each term step‑by‑step:
- 21st‑century Agentic AI — why agents are natural‑language‑programmed programs
- LLMs as agents — how reasoning, memory, and protocols turn models into actors
- Domain‑agnostic Context Engine — the universal core that runs any use case
- Dual‑RAG MAS — the two‑channel research architecture (instructions + facts)
- Environment design — how telemetry, context layers, and MCP orchestrate agents
- Full drill‑down to code — notebooks, pipelines, and execution traces
- Full climb back up — how the code re‑forms the architecture end‑to‑end
📺Watch the full deep dive on LinkedIn
If you are an architect or lead looking for:
✅ ROI & Domain Agnosticism logic
✅ Glass-Box Observability traces
✅ Sovereign RAG blueprints
Join the engineering discussion here: Link to GitHub Discussion
🗺️ One Architecture, Three Editions
Everything below — LangChain, Sovereign, NIM Nemotron — is the same engine: the same planner, the same two governance gates, the same dual-RAG namespaces, the same domain-agnostic registry. What changes across the three sections is only which model answers the calls and which framework carries the plumbing.
The architecture is the product. The model, the framework, and the code are all deployment choices.
🛡️ The LangChain Edition of the Universal Context Engine
The Universal Context Engine, ported onto LangChain 1.x and LangGraph 1.x, reading the same Pinecone index, the same namespaces, and using the same OpenAI models as the original. This folder is the repository's framework pole. sovereign_ai/ is the other: zero framework, zero external API, maximum control. Between them they make one point, which is the point of the book:
The architecture is the product. The framework is a deployment choice.
</a>
🛡️ Sovereign AI & Open-Source Engineering
For organizations requiring 100% data privacy and zero external API dependencies, this repository provides a dedicated Sovereign Path.
By leveraging high‑reasoning open‑source models like DeepSeek‑R1, you can achieve industrial‑grade performance entirely on your own infrastructure.
🔑 Key Highlights of the Sovereign Path
⚡Performance: Benchmarked at ~9.75 seconds on NVIDIA H100 hardware for complex multi‑step reasoning.
🔍Transparency: Provides 100% Glass‑Box observability using local reasoning traces (</think> blocks).
🛠️Independence: Fully disconnected execution with no vendor lock‑in and no unpredictable API costs.
Read the DeepSeek-R1 Sovereign AI Guide and the Hardware benchmark notebook
</a>
🛡️ The NVIDIA NIM NEMOTRON Edition of the Universal Context Engine
What the NVIDIA NIM Nemotron version adds to the universal content engine:
Nemotron is a hybrid: most of its self-attention layers are replaced by Mamba-2 state-space layers, with only a thin residual of attention retained — so context is carried in a fixed-size recurrent state rather than a KV cache that grows with every token, and throughput stays roughly linear in sequence length instead of quadratic.
The DAG mirrors that optimization one level up: where Mamba drops the quadratic all-to-all of attention and mixture-of-experts activates only the parameters a token needs, the planner drops the unnecessary edges of a linear chain and the Foreman runs only the nodes whose dependencies are actually met — sparsity and parallelism in the orchestration, matching sparsity and parallelism in the silicon.
</a>
🐳☁️ Docker + Railway Deployment: The NIM Nemotron engine is also packaged as a deployable FastAPI service — build it with Docker, ship it to Railway, and verify it live via Swagger.
See the full Docker & Railway deployment guide
☸️ Also deployed and verified on Kubernetes with the same Docker container image that runs with concurrent requests
🛡️ The Claude Projects Edition of the Universal Context Engine
The Context Engine with no code at all.
Every other edition in this repository swaps the model or the framework. This one removes the program.
The Universal Context Engine runs entirely as natural-language protocol files inside a Claude Project: nine markdown files uploaded to the Project's knowledge, and one block of text pasted into its instructions. No Python. No API keys. No Pinecone. No embedding model. Nothing installed. The full pipeline is intact — Gate 1 → Plan → Gate 2 → Execute → Trace — with a dynamic DAG planner, cross-domain governance, dual RAG, per-document injection screening, and a glass-box trace.
sovereign_ai/ proves the architecture survives without an external API. langchain/ proves it survives on someone else's framework. claude_projects/ proves it survives without code, which is the strongest available evidence for the claim the book makes: the Context Engine was never a program, it is a set of contracts, and the Python was a carrier.
Three layers, and only the middle one changes when the use case does:
A new use case is therefore a new set of data files, not a new engine. Point 50_Pack_Builder.ipynb at a folder of documents and it writes the packs for you: the same job Data_Ingestion_Marketing.ipynb does, with markdown files as the destination instead of a vector index, and with an ingestion-time injection screen the original could not have. No API keys.
What this edition adds to the Chapter 6-8 lineage: a DAG in place of $$STEP_N_OUTPUT$$ linear chaining, Gate 2 — which Chapter 6-8 could not have, because a list of steps has no edges to govern — seven governance domains with the Domain:Agent A2A seam, injection rejections reported in the trace rather than silently logged, and orphan-node detection at planning time.
The README carries a full captured transcript of a PLAN: run — Gate 1, the emitted DAG, all six Gate 2 checks with their verdicts, and the trace — plus the input, expected output, and what failure looks like for all nine control decks. The trade-offs are documented honestly, including the one that matters: with no code, Gate 2 is a protocol a model follows rather than a function that must run.
Read the Claude Projects guide
</a>
💡 Because there is nothing to install, this is the fastest way to read the whole architecture: the entire engine is five markdown files, and there is nothing in them but the design.
✅ Prerequisites
- Python: Version 3.10+
- Environment Options:
- Google Colab or
- Local Python environment with:
openaipinecone# (formerlypinecone-client— the package was renamed)tiktokentenacitynest_asyncio# required by the NIM edition's notebook (Colab kernel + asyncio)fastapi# only if you run the Gradio/deployment notebooks in Chapter 10
🚀 Quick Start
Get up and running using cloud-based virtual machines using the Google Colab links provided for each notebook.
No local installation is required.
1. Get Your API Keys
- OpenAI: Sign up and generate a key at platform.openai.com.
- Pinecone: Sign up and generate a free API key at pinecone.io.
- NVIDIA NIM (only for the NIM edition): free key at build.nvidia.com.
2. Run the Notebooks
Click the badges below to launch the notebooks directly in a pre-configured Google Colab VM. You will be asked to add your API keys to the Colab Secrets Manager upon launch.
✅ Project Structure
Create a GitHub or local workspace containing at least:
helpers.pyagents.pyregistry.pyengine.py- Notebook files for each chapter
✅ Required API Keys
- OpenAI – model access and moderation
- Pinecone – vector database storage and retrieval
- NVIDIA NIM (NIM edition only) – planning and agent inference
- (Optional) Google Cloud or AWS – for deployment sections in Chapter 10
✅ System Requirements
Note: From Chapter 5 onward, modular components depend on earlier notebooks. Ensure your environment is configured correctly, as setup steps may not be repeated in later chapters.
✅ Additional Notes
- Local execution may incur token and API costs with large contexts.
- The Summarizer Agent (Chapter 6) helps reduce token usage.
- Familiarity with RAG workflows and MCP-based agent orchestration is recommended.
- Refer to Appendix: Context Engine Reference Guide for quick lookup of component structures and explanations.
Denis Rothman is an AI systems architect and author whose work bridges foundational AI research with today’s generative and agentic architectures. A graduate of Sorbonne University and Paris‑Diderot University, he designed one of the earliest patented word2matrix numerical encoding systems which was a precursor to modern embedding techniques. He designed one of the first industrial conversational agents, deployed as an automated language teacher for Moët & Chandon and other global companies. Throughout his career, Denis has built large‑scale AI systems across industries, from IBM resource optimizers to worldwide Advanced Planning and Scheduling (APS) solutions, always focusing on transparent, explainable, and production‑ready architectures. Building on decades of applied AI engineering, he has become a leading voice in the agentic era of AI, authoring influential books on transformers, RAG pipelines, business‑ready generative AI, and now Context Engineering for Multi‑Agent Systems. His work emphasizes model‑agnostic engineering, semantic design, and the construction of resilient, domain‑independent AI systems that go far beyond prompting. Denis continues to publish hands‑on frameworks, open‑source architectures, and practical guides that help engineers, researchers, and organizations build the next generation of verifiable, context‑driven AI systems.
We welcome contributions! High interaction through Issues, PRs, and Comments helps the Context Engine grow and improves the trending visibility for the community.
How to get started:
- Check Issues: Look for the good first issue label for approachable tasks.
- Discussions: Join our Discussions tab to propose new features or "Context Chaining" techniques.
- Pull Requests: Submit improvements to the core
engine.pyor new specialized agents inagents.py.
Cool code is great.
But without a compelling Return on Investment (ROI), it will never survive in production.
Agentic AI should therefore be evaluated on more than model capability or technical sophistication:
Capability → Context → Governance → Execution → Measurable Business Value
The objective is not to build the most impressive demo.
The objective is to build systems that are useful, governable, measurable, and economically sustainable.
What happens when an AI architecture can act?
This is where my thinking about the architecture is evolving.
I think we are crossing an important architectural boundary in agentic AI.
OpenAI describes GPT-6 Astra as state-of-the-art in computer use, with the ability to carry out multi-step workflows across browsers, software and professional environments.
I have now added a computer-use capability to my Context Engineering for Multi-Agent Systems repository.
But the interesting part isn't the model.
It is the architecture around the model.
The repository now demonstrates a progression:
Context → Reasoning → Perception → Action → Environment → Observation → Context
And that capability sits alongside:
- Dual high-fidelity RAG
- Multi-agent orchestration
- MCP
- Telemetry
- Governance gates
- Glass-box traces
- Prompt-injection defenses
- Token/cost analytics
- Sovereign/local execution
- Human oversight
The same architectural contracts are demonstrated across different substrates: OpenAI, LangChain/LangGraph, DeepSeek-R1, NVIDIA Nemotron, Claude Projects — and now computer use with GPT-6 Astra.
That leads to a distinction I think will become increasingly important:
The model is not the agentic system.
The model provides intelligence.
The protocol provides the contract.
The harness provides controlled execution.
The environment provides the world in which actions have consequences.
And governance determines what the system is allowed to do.
This is also why I am deliberately treating computer use as a capability of the Context Engine, rather than creating another "model edition."
It extends the architecture rather than replacing it.
The repository is educational — not an operational deployment — and is being developed alongside my book, training sessions and corporate workshops.
The goal is to make the architecture visible, testable and teachable, including the uncomfortable parts: sovereignty, security, governance and human control.
I also think this changes the scope of what we mean by context engineering.
When an AI system only generates text, context largely determines what the system knows, remembers and reasons about.
When the system can perceive and act, context becomes part of a much larger control loop.
It determines what the agent can understand, what environment it can observe, what actions it can consider, what tools it can access, what permissions it has, and what evidence is captured after it acts.
That is a very different engineering problem.
And it is one reason I believe the architecture around increasingly capable models matters as much as the models themselves.
Because once an AI system can perceive and act, context engineering is no longer only about what an agent knows.
It is also about what it can see, what it can do, and what we allow it to do.
The Potential Architectural Shift
This raises another critical question for me. Where should deterministic automation end and agentic automation begin?
If we combine a sovereign, governable Context Engine with organizational anchors, domain knowledge, governance controls, and a full domain-agnostic context architecture — and then add the perception-and-action capability of GPT-6 Astra — could we simplify some of the increasingly cumbersome automation stacks used in large enterprises?
I don't mean simply replacing RPA.
I mean reconsidering where we need RPA, workflow engines, Microsoft automation components, custom integrations, or any automated ordering tool in the first place.
Traditional enterprise automation often looks something like:
Process → Script → Application → Result
The agentic architecture I am exploring looks more like:
Context → Reasoning → Governance → Action → Environment → Observation → Context
With computer use, the agent can potentially operate existing enterprise applications through their interfaces rather than requiring every interaction to be represented as a separate deterministic integration.
That creates an interesting architectural possibility:
┌─────────────────────┐
│ Enterprise Context │
│ │
│ Policies │
│ SOPs │
│ Domain Knowledge │
│ RAG / Memory │
│ Organizational │
│ Anchors │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Reasoning / Planning│
└──────────┬──────────┘
│
Governance Gate
│
▼
┌─────────────────────┐
│ GPT-6 Astra │
│ Perception + Action │
└──────────┬──────────┘
│
▼
┌─────────────────────────────────┐
│ Existing Enterprise Environment │
│ │
│ ERP │ CRM │ Browser │ Microsoft │
│ Legacy Apps │ Web Apps │ etc. │
└────────────────┬────────────────┘
│
▼
Observation / Evidence
│
▼
Context + Audit Trail
That changes the proposition from:
How do we automate this application?
to:
How do we govern an intelligent system that can accomplish this business outcome across the applications we already use?
For me, that is a much more interesting question.
And it brings the discussion directly back to ROI.
The objective should not be to replace a technology simply because a newer technology exists.
The objective should be to determine whether the new architecture can produce measurable improvements.