Status: Concept / Architecture Proposal
Proposed Package: agentic-sidecar
This document describes the long-term architecture vision — including framework independence, the full seven-outcome Decision Gate, and a published Intent Envelope schema. None of that is scoped to the first release. For the phased, currently-committed build plan — starting with a single LangGraph adapter, zero LLM calls, and
ALLOW/BLOCKonly — see ROADMAP.md.
Agentic Sidecar is a framework-independent companion intelligence layer that operates alongside an autonomous AI agent.
The primary agent remains responsible for executing the user’s task. The Sidecar does not replace the primary agent or become another worker in a multi-agent workflow.
Instead, it independently helps the primary agent:
The fundamental architectural principle is:
The Main Agent acts. The Sidecar observes, thinks, advises, injects the relevant intent at each decision point, and governs.
This creates separation between task execution and decision supervision.
As AI agents become increasingly autonomous, an agent may perform long chains of reasoning and actions:
User
↓
Agent
↓
Planning
↓
Sub-Agent
↓
MCP
↓
Tool
↓
API
↓
External System
Several problems emerge.
The original request may become distorted during a long execution.
Example:
Original intent:
"Investigate why production is slow."
Later agent decision:
"Restart the production database."
Investigating a problem does not necessarily authorize changing production.
An agent may technically have permission to invoke a tool while still making an inappropriate decision.
Traditional authorization asks:
Can this agent call refund_customer()?
Agentic Sidecar additionally asks:
Should the agent call refund_customer()
in this situation and under the user's original intent?
Long-running agents can perform many operations without users understanding what is happening.
Users need answers to questions such as:
The same model responsible for making a decision should not necessarily be the only system evaluating that decision.
Agentic Sidecar allows an independent model or reasoning mechanism to challenge the executor.
USER
│
User Intent
│
▼
┌───────────────┐
│ MAIN AGENT │
│ EXECUTOR │
└───────┬───────┘
│
Plans / Decisions
│
▼
┌─────────────────────┐
│ AGENTIC SIDECAR │
│ │
│ Intent Guardian │
│ Planner │
│ Critic │
│ Judge │
│ Risk Evaluator │
│ Policy Advisor │
│ Decision Gate │
│ Status Interpreter │
└──────────┬──────────┘
│
Advice / Approval / Challenge
│
▼
MAIN AGENT
│
▼
MCP / Tools
│
▼
External Systems
The Sidecar is attached to the execution lifecycle but does not own the user’s task.
Responsible for:
Responsible for:
This distinction is essential.
Agentic Sidecar should not simply become another worker agent.
The Sidecar should use a modular architecture.
Possible modules include:
Agentic Sidecar
│
├── Intent Guardian
├── Planner
├── Critic
├── Judge
├── Risk Evaluator
├── Policy Advisor
├── Decision Gate
├── Budget Guardian
├── Status Interpreter
└── Human Escalation
Users should be able to enable only the capabilities they need.
Example configuration:
sidecar:
intent:
enabled: true
preserve_original_intent: true
planner:
enabled: true
critic:
enabled: true
judge:
enabled: true
model: independent-model
risk:
enabled: true
intervention_threshold: 0.80
policy:
enabled: true
source: policies.yaml
budget:
enabled: true
max_cost: 2.00
human_approval:
enabled: true
One of the flagship capabilities of Agentic Sidecar should be intent preservation.
When a user initiates a task, the Sidecar converts the request into a structured Intent Envelope.
Example:
intent:
goal:
refund_customer
requested_by:
type: human
id: user123
constraints:
maximum_refund: 500
customer:
C8291
reason:
order_not_delivered
authority:
refund_allowed: true
expires:
2026-08-10T00:00:00Z
The Sidecar maintains this intent throughout execution.
The Sidecar can inject relevant intent information into the agent’s decision context.
Instead of expecting the primary agent to remember the original instructions throughout a long workflow:
Original User Intent
↓
Sidecar
↓
Intent Envelope
↓
Relevant Intent Injection
↓
Main Agent Decision
Only the relevant intent and constraints need to be injected at each decision boundary.
As the agent progresses through multiple steps, the Sidecar continuously evaluates:
Original Intent
│
▼
Agent Plan
│
▼
Still aligned?
│
▼
Agent Decision
│
▼
Still aligned?
│
▼
Tool Action
This introduces the concept of Agent Goal Drift / Intent Drift Detection.
The Sidecar can determine whether the agent’s current action is still consistent with:
Traditional authorization evaluates permissions:
Is Agent X allowed to call Tool Y?
Agentic Sidecar can introduce an additional layer:
Is Agent X's use of Tool Y consistent
with the user's intent and granted authority?
For example:
Agent permission:
refund_customer()
→ ALLOWED
But:
User intent:
Maximum refund = $500
Agent proposes:
Refund = $850
Sidecar:
INTENT VIOLATION
The tool may technically be permitted while the specific action is semantically inappropriate.
The Sidecar can independently evaluate the Main Agent’s plan.
Example:
MAIN AGENT
Plan:
1. Query customer
2. Query orders
3. Cancel subscription
4. Refund payment
↓
SIDECAR PLANNER
User only requested:
"Explain why I was charged."
Cancellation and refund are unnecessary.
Recommendation:
Replan.
The Main Agent remains responsible for execution.
The Sidecar can act as an independent critic.
Before important decisions:
Main Agent
↓
Proposed Decision
↓
Sidecar Critic
↓
Challenge / Accept
↓
Main Agent
The critic can look for:
The Sidecar can optionally use another LLM as an independent judge.
Importantly:
Main Agent Model
≠
Sidecar Judge Model
For example:
Main Agent
Provider / Model A
│
↕
Agentic Sidecar
Provider / Model B
Using heterogeneous models may reduce correlated reasoning failures.
The Sidecar architecture should remain model-agnostic.
Not every Sidecar decision needs an expensive frontier model.
Possible architecture:
Large Main LLM
+
Small Local Sidecar
A lightweight model could perform:
A larger judge model could only be invoked for ambiguous or high-risk decisions.
The Sidecar should not necessarily inspect every token generated by an agent.
Instead, it can activate at decision boundaries.
Examples:
This reduces:
A Decision Gate determines whether an action can continue.
Example:
READ DATABASE
↓
Low Risk
↓
EXECUTE
Compared with:
DELETE DATABASE
↓
High Risk
↓
SIDECAR DECISION GATE
↓
┌─────┼───────┐
↓ ↓ ↓
Allow Block Human Approval
Possible outcomes include:
ALLOW
WARN
CHALLENGE
REPLAN
PAUSE
BLOCK
ESCALATE
For consequential operations, the Sidecar can pause execution.
Example:
Agent:
Preparing refund: $850
Sidecar:
⚠ INTENT VIOLATION
Original authorization:
Maximum refund: $500
Execution paused.
Available actions:
[Approve Once]
[Reject]
[Modify Intent]
[Ask Agent to Replan]
[Stop Agent]
This creates real-time human control over autonomous execution.
Agentic Sidecar can provide real-time visibility into what the agent is doing.
Example:
┌─────────────────────────────────────────────┐
│ Research Agent ● RUNNING │
├─────────────────────────────────────────────┤
│ │
│ GOAL │
│ Recommend architecture for workload X │
│ │
│ CURRENT STEP │
│ Evaluating database options │
│ │
│ LIVE ACTIVITY │
│ │
│ ✓ Web Search 1.2s │
│ ✓ MCP → Cloud Documentation 0.8s │
│ ✓ Planner 0.4s │
│ ● Calling pricing API... │
│ ○ Compare results │
│ ○ Generate recommendation │
│ │
│ SIDECAR │
│ │
│ Intent Alignment 94% │
│ Risk LOW │
│ Budget $0.18/$1.00 │
│ │
│ [ PAUSE ] [ STOP ] [ INTERVENE ] │
└─────────────────────────────────────────────┘
Users should be able to see which tools the agent is currently using.
For developers:
Agent
↓
MCP: aws-documentation
↓
Tool: search_documentation
↓
API request
↓
Result
Possible information:
Sensitive values should be redacted automatically.
Technical traces are useful for engineers but not always appropriate for normal users.
The Sidecar can translate low-level execution events into understandable status updates.
Instead of:
GET /orders/182
POST /customer/search
MCP tool_call
LLM completion
show:
🔎 Looking up your order
📦 Checking shipment history
🧠 Determining whether refund criteria are met
⚠ Found conflicting information — verifying
👤 Approval required before issuing refund
💳 Processing approved refund
✅ Task completed
This creates an understandable live narrative of autonomous execution.
The UI can evolve into an Agent Control Room.
The Control Room provides:
Controls could include:
PAUSE
RESUME
STOP
INTERVENE
MODIFY INTENT
APPROVE ONCE
REJECT ACTION
ASK AGENT TO REPLAN
A typical operation could look like:
User Request
│
▼
Sidecar captures intent
│
▼
Main Agent creates plan
│
▼
Sidecar evaluates plan
│
▼
Main Agent begins execution
│
▼
Tool action proposed
│
▼
Decision boundary detected
│
▼
Sidecar evaluates:
Intent
Risk
Policy
Authority
Cost
│
▼
Decision
│
┌────┼─────────┬──────────┐
▼ ▼ ▼ ▼
Allow Warn Replan Human Approval
│
▼
Tool executes
│
▼
Result returned
│
▼
Live status updated
User says:
Clean unused resources from our DEV environment.
The Sidecar captures:
goal:
clean_unused_resources
environment:
dev
production_changes:
prohibited
The Main Agent discovers 400 resources and proposes deleting them.
The Sidecar evaluates the list.
363 resources → DEV
37 resources → Production
The Sidecar responds:
HIGH RISK
37 proposed resources appear production-related.
Original intent restricts execution to DEV.
Recommendation:
Remove production resources from the plan and regenerate
the deletion set.
The Main Agent replans.
Only the 363 DEV resources are considered.
The Sidecar approves.
Execution continues.
An Agent Harness provides the control and execution environment in which an agent operates — managing the agent loop, tools, state, context, retries, and execution lifecycle.
Agentic Sidecar does not replace the harness. It strengthens it.
Agent Harness = control and execution loop.
Agentic Sidecar = decision-time supervision layer for that loop.
The harness helps the agent execute. The Sidecar helps ensure that what gets executed is still aligned with what the human originally intended.
As an agentic task moves through a chain of agents, sub-agents, MCP servers, and tools, the original user intent can become increasingly distant from the component making the next decision.
Human Intent
│
▼
Agent A
│ delegates
▼
Agent B
│ delegates
▼
Agent C
│
▼
MCP / Tool
Each downstream agent may receive the immediate task it needs to perform without necessarily retaining the full context, constraints, authority, and boundaries of the original request.
Agentic Sidecar addresses this through the Intent Envelope (Section 6).
Instead of relying on every downstream agent to reconstruct the user’s intent from conversation history, the Sidecar can make the relevant intent available again at decision boundaries:
Human
│
└── Intent Envelope
│
▼
Agent A
│
[Intent]
▼
Agent B
│
[Intent]
▼
Agent C
│
[Intent]
▼
MCP / Tool
The goal is not to repeatedly inject the entire conversation. The goal is to propagate the minimum structured intent necessary to make the next decision safely — for example:
This gives downstream decision makers a consistent answer to:
“What was the human actually trying to accomplish, and is this action still within that intent?”
Potentially — but primarily by making the harness more controlled and reliable, rather than by making the underlying model faster.
Without an independent supervision layer, a harness may discover problems only after an action fails, a plan drifts, or another agent has to reason again about missing context.
The Sidecar introduces decision-time checks that can catch those problems earlier:
Plan → Act → Fail → Recover → Replan
vs.
Plan → Sidecar Check → Act
│
├── ALLOW
├── CHALLENGE
├── REPLAN
├── BLOCK
└── ESCALATE
This can reduce unnecessary actions, repeated reasoning, unsafe retries, and context reconstruction while keeping execution aligned with the original request.
The Sidecar therefore complements the harness:
Harness: How do I execute this agentic workflow?
Sidecar: Should this decision happen, given what the human originally asked for?
Agentic Sidecar should be explicitly differentiated from normal multi-agent architectures.
Typical multi-agent system:
Agent A → Research
Agent B → Code
Agent C → Review
Agent D → Execute
Each agent owns part of the task.
Agentic Sidecar:
Main Agent
│
│ owns task
│
↕
Sidecar
│
does NOT own task
│
independently supervises
The Sidecar exists because the Main Agent exists.
It accompanies the executor throughout its lifecycle.
LLM-as-a-Judge is one possible Sidecar capability.
It is not the entire architecture.
Agentic Sidecar
│
├── Intent Guardian
├── Planner
├── Critic
├── LLM Judge
├── Risk Evaluator
├── Decision Gate
├── Policy Advisor
├── Status Interpreter
└── Human Escalation
This distinction is important for positioning.
There should be a clean separation between AgenticLens and Agentic Sidecar.
Focus:
Observe, trace, analyze and provide evidence.
Examples:
Focus:
Supervise and influence execution while it is happening.
Examples:
A simple distinction:
AgenticLens
"What did the agent do?"
"What happened?"
"Why did it fail?"
versus:
Agentic Sidecar
"What is the agent doing?"
"Should it continue?"
"Is it still following my intent?"
"Should someone intervene?"
AgenticLens can provide telemetry consumed by the Sidecar without the two projects becoming duplicates.
Agentic Chaos intentionally introduces failures and adverse conditions to evaluate agent resilience.
Agentic Chaos
↓
Break / Stress / Degrade
↓
Agent
Agentic Sidecar supervises the agent’s decisions during normal or abnormal execution.
An interesting integration is:
Agentic Chaos
↓
inject failure
↓
Main Agent
↓
attempts recovery
↓
Agentic Sidecar
↓
evaluates recovery decision
This enables testing not only whether the agent survives failure, but whether it makes appropriate recovery decisions.
Agentic MCP handles connectivity and interaction with MCP environments.
Conceptually:
Agentic MCP
Agent → Tools
Agentic Sidecar adds:
Agent → Decision → Sidecar → MCP → Tool
The Sidecar can understand:
The projects can represent different layers of the agent lifecycle.
AUTONOMOUS AGENT
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
AgenticLens Agentic Sidecar Agentic MCP
│ │ │
Observe Govern Connect
Analyze Guide Integrate
Evidence Intervene Tools
│ │ │
└──────────────┼──────────────┘
│
▼
Agentic Chaos
│
Break / Test
│
▼
Validate
This gives the ecosystem four distinct responsibilities:
AgenticLens
OBSERVE
Agentic Chaos
TEST
Agentic MCP
CONNECT
Agentic Sidecar
GUIDE + GOVERN
A simple developer experience could look like:
from agentic_sidecar import Sidecar
sidecar = Sidecar(
roles=[
"intent_guardian",
"planner",
"critic",
"risk"
]
)
agent = sidecar.attach(my_agent)
agent.run(
"Investigate the production issue but do not modify production."
)
Decision interception:
@sidecar.before_tool_call
def evaluate_action(context):
return sidecar.evaluate(
intent=context.intent,
action=context.tool_call,
risk=context.risk
)
Possible response:
Decision(
status="REPLAN",
risk="HIGH",
reason="Action exceeds original user intent"
)
A major design objective should be framework independence.
Potential integrations:
LangGraph
LangChain
OpenAI Agents
Microsoft Agent Framework
CrewAI
AutoGen
Google ADK
Custom Agents
MCP-based Agents
The conceptual model should remain:
Any Agent
+
Agentic Sidecar
This would make Sidecar an infrastructure layer rather than another agent framework.
Main Agent and Sidecar should not need to use the same model.
Example:
Main Agent
│
GPT / Claude / Gemini / Local
│
↕
Agentic Sidecar
│
Different LLM / Small Model / Rules Engine
A Sidecar could even combine several evaluators:
Sidecar
│
┌─────────┼─────────┐
▼ ▼ ▼
Rules Small LLM Judge LLM
The cheapest appropriate evaluator can handle each decision.
A naive Sidecar that invokes another LLM for every operation could approximately double inference cost and increase latency.
Therefore the architecture should support selective activation.
Example:
Agent Action
│
▼
Risk Classifier
│
┌───┴────┐
▼ ▼
LOW HIGH
│ │
Execute Sidecar LLM
│
▼
Decision
Possible strategies:
Agentic Sidecar could support several modes.
Sidecar monitors execution but cannot affect it.
Agent → Sidecar observes → Agent continues
Sidecar provides recommendations.
Agent → Sidecar → recommendation → Agent decides
Sidecar can enforce decisions.
Agent → Sidecar Gate → Allow / Block
Agent
↓
Sidecar
↓
High-risk decision
↓
Human
↓
Approve / Reject
This makes adoption easier because organizations can gradually increase Sidecar authority.
The project creates several research directions.
Does Sidecar-based supervision reduce intent drift in long-running autonomous workflows?
Does using a different model for Sidecar evaluation reduce correlated failures?
At which execution boundaries does intervention provide the greatest reliability improvement?
How much additional inference cost is required for measurable reliability improvement?
Can Sidecar-generated status and intervention requests allow humans to effectively supervise autonomous agents?
Can selective Sidecar invocation achieve similar reliability improvements to continuous evaluation at significantly lower cost?
The Sidecar should eventually be evaluated empirically.
For example:
Baseline:
Agent Alone
Accuracy: 72%
Unsafe Decisions: 14%
Intent Violations: 11%
Cost: $X
Latency: X sec
Compared with:
Agent + Sidecar
Accuracy: 91%
Unsafe Decisions: 3%
Intent Violations: 2%
Sidecar Intervention: 17%
Cost: $Y
Latency: Y sec
Important metrics could include:
This evidence would make the project substantially stronger than relying only on architectural claims.
The Intent Envelope could eventually become independently useful.
Conceptually:
Human Intent
↓
Structured Intent Envelope
↓
Main Agent
↓
Sub-Agent
↓
MCP
↓
Tool
The envelope could preserve:
WHO requested the action
WHAT they requested
WHY they requested it
WHAT constraints exist
WHAT authority was granted
WHAT authority was NOT granted
WHEN that authority expires
WHICH parent intent created this action
This could eventually evolve into a broader interoperability specification rather than remaining an internal Sidecar structure.
Longer term, Agentic Sidecar could enable:
User Intent
↓
Intent Envelope
↓
Agent
↓
Sidecar
↓
Sub-Agent
↓
Sidecar
↓
MCP
↓
Tool
Every important action could be evaluated against its originating intent.
This creates an intent-aware execution chain for autonomous systems.
Avoid positioning Agentic Sidecar simply as:
“Another LLM that watches your LLM.”
That undersells the architecture and makes it sound like a standard multi-agent pattern.
Better positioning:
Agentic Sidecar is a companion intelligence and real-time supervision layer for autonomous AI agents.
Or:
An independent decision-supervision layer that helps autonomous agents preserve intent, evaluate risk, and safely execute consequential actions.
Short positioning:
See. Guide. Govern. Your agents while they work.
The central differentiation should be:
The Sidecar does not own the user’s task. It independently observes and influences the decision process of the executor agent.
That separates Agentic Sidecar from:
Those technologies can instead become components or integrations of the Sidecar architecture.
The first version should remain focused.
Provide:
Provide:
Provide:
Provide:
Provide:
This sequence avoids trying to build every Sidecar capability immediately.
Agentic Sidecar can evolve from a Python library into an architectural layer for autonomous systems.
This is the harness relationship described in Section 23, extended to its full form: the Sidecar living inside the harness boundary as the decision-time supervision layer for the executor’s loop.
The long-term model becomes:
┌──────────────────── AGENT HARNESS ───────────────────┐
│ │
│ User Intent │
│ ↓ │
│ ┌─────────────┐ │
│ │ MAIN AGENT │ Plan → Act → Observe → Refine │
│ └──────┬──────┘ │
│ │ │
│ │ │
│ │ proposed decisions │
│ ▼ │
│ ┌──────────── AGENTIC SIDECAR ─────────────┐ │
│ │ Intent Guardian │ │
│ │ Planner / Critic / Judge │ │
│ │ Policy + Risk │ │
│ │ Decision Gate │ │
│ │ Human Escalation │ │
│ └─────────────────┬────────────────────────┘ │
│ │ │
│ allow / challenge / │
│ replan / block │
│ ↓ │
│ Another Agent / Tools / MCP │
│ ↓ │
│ External Systems │
└──────────────────────────────────────────────────────┘
The Sidecar becomes the companion intelligence sitting between autonomous reasoning and consequential action.
Together, the ecosystem can address four fundamental questions about autonomous AI systems:
What is the agent doing, and what happened?
OBSERVE
How does the agent behave when things go wrong?
TEST
How does the agent interact with tools and external capabilities?
CONNECT
Should the agent continue with this decision, and is it still acting according to intent?
GUIDE + GOVERN
Together:
DeepAgentLabs
Autonomous AI Systems
│
┌─────────────┼─────────────┐
│ │ │
OBSERVE GUIDE CONNECT
│ │ │
AgenticLens Agentic Sidecar Agentic MCP
│ │ │
└─────────────┼─────────────┘
│
TEST
│
Agentic Chaos
The objective is not to create many unrelated PyPI packages.
The objective is to create complementary infrastructure for building observable, resilient, connected, intent-aware, and governable autonomous AI systems.