The 6‑Layer Architecture of AI Agents: Perception, Planning, Tools, Memory, Execution, and Feedback

Overview: The 6‑Layer Architecture

In 2024 ChatGPT showcased conversational large‑model abilities, in 2025 Manus highlighted autonomous execution, and in 2026 OpenClaw put agents in the hands of everyone. A real AI Agent is far more than "adding a tool call" to a large model; it is a full cognition‑action system composed of six layers.

The six layers form a closed loop rather than a linear pipeline: Perception → Planning → Execution → Feedback → Perception → …

Layer 1 – Perception : How does the agent understand input? (Analogy: human eyes and ears)

Layer 2 – Planning : How does the agent decompose tasks? (Analogy: prefrontal cortex)

Layer 3 – Tools : How does the agent extend its capabilities? (Analogy: human hands and toolbox)

Layer 4 – Memory : How does the agent retain state? (Analogy: hippocampus)

Layer 5 – Execution : How does the agent act? (Analogy: muscles and nerves)

Layer 6 – Feedback : How does the agent self‑correct? (Analogy: pain perception and learning)

Layer 1 – Perception (Agent’s "Eyes" and "Ears")

1.1 What the Perception Layer Does

The responsibility of the perception layer is to convert raw input into a structured representation that the agent can understand. Errors here cause garbage‑in‑garbage‑out for all downstream layers.

Input Types :

User natural‑language command
↓ Intent, entities, constraints extraction
Multimodal input (image, audio, video)
↓ Cross‑modal alignment, feature extraction
Environment state (API response, file content, DOM)
↓ Structuring, noise filtering
Tool execution result
↓ Parse return value, detect errors

1.2 Core Techniques

Intent recognition & entity extraction – Example: user says "Help me find tomorrow’s flight from Beijing to Shanghai, economy class, under 2000 CNY." The perception layer must output a JSON like:

{
  "intent": "search_flight",
  "entities": {
    "departure": "北京",
    "arrival": "上海",
    "date": "2026-06-19",
    "cabin_class": "economy",
    "max_price": 2000,
    "currency": "CNY"
  },
  "constraints": ["price <= 2000", "cabin = economy"],
  "missing_info": ["departure_time_preference"]
}

Multimodal perception – Flagship models in 2026 (Gemini 2.5 Ultra, GPT‑5.5, Claude Opus 4) can process video, but for agents the key is turning visual data into actionable structured data. For a web‑page screenshot the agent must:

Identify layout (header, sidebar, main content)

Locate interactive elements (buttons, inputs, links)

Extract key information (price, date, status)

This is why benchmarks such as WebArena and OSWorld are hard: perception must "see" and also "understand".

1.3 Engineering Practices – Three Key Designs

Design 1: Input Normalization Pipeline

class PerceptionPipeline:
    def __init__(self):
        self.parsers = {
            "text": TextParser(),
            "image": ImageParser(),
            "audio": AudioParser(),
            "api_response": APIResponseParser(),
        }
    def perceive(self, raw_input: Any, input_type: str) -> StructuredInput:
        parser = self.parsers[input_type]
        parsed = parser.parse(raw_input)
        # unified normalization
        normalized = StructuredInput(
            intent=parsed.extract_intent(),
            entities=parsed.extract_entities(),
            constraints=parsed.extract_constraints(),
            context=parsed.extract_context(),
            confidence=parsed.confidence_score()
        )
        if normalized.confidence < 0.7:
            raise AmbiguousInputError(normalized)
        return normalized

Design 2: Confidence Gating – When the agent is uncertain about the user’s intent, it should actively request clarification instead of guessing.

Design 3: Incremental Perception – For long tasks, process input incrementally and re‑perceive the environment after each step:

while not task_complete:
    current_state = perceive(environment)
    plan = planner.update_plan(current_state)
    result = executor.execute(plan.next_step)
    feedback = feedback_layer.evaluate(result)
    # loop back to perception

1.4 Common Pitfalls

Intent drift : after several dialogue turns the agent forgets the original goal. Solution: inject the original intent anchor at every perception step.

Environment mis‑read : treating an API error as success. Solution: structurally validate return values instead of trusting the LLM.

Multimodal noise : OCR introduces irrelevant text. Solution: pre‑process to keep only structured information.

Layer 2 – Planning (Agent’s "Brain")

2.1 What the Planning Layer Does

The planning layer is the agent’s command centre. Its job is to break a complex goal into an executable sequence of steps, consider resource constraints, and prioritize sub‑goals—just like humans decompose a problem.

2.2 Core Planning Paradigms

Paradigm 1: ReAct (Reasoning + Acting) – Each step follows a Thought → Action → Observation loop. Example:

Thought: I need to check the user’s order history.
Action: search_orders(user_id=12345)
Observation: Found 3 orders, all electronics...
Thought: User prefers electronics, recommend the latest model.
Action: recommend_product(category="electronics", sort="latest")
Observation: Recommendation list contains 5 products...

Pros: simple, interpretable. Cons: re‑reasoning at every step makes it inefficient.

Paradigm 2: Plan‑then‑Execute – Generate a full plan first, then execute step by step.

Plan:
  Step 1: Query user profile
  Step 2: Retrieve candidate set
  Step 3: Rank & filter
  Step 4: Generate narrative
  Step 5: Send recommendation
Execute Step 1… ✅
Execute Step 2… ✅
Execute Step 3… ❌ (API timeout)
Replan: use cached data
Execute Step 3 (revised)… ✅

Pros: global view, higher efficiency. Cons: plan may become invalid if the environment changes.

Paradigm 3: Tree‑of‑Thought – Explore multiple reasoning paths and pick the optimal one. The article shows a decision tree for system‑performance optimization, comparing impact, cost, and risk.

Paradigm 4: Hierarchical Planning – High‑level strategic planner delegates to lower‑level tactical planners. This is the mainstream architecture for multi‑agent systems in 2026.

2.3 Engineering Implementation

Core component: PlanManager

class PlanManager:
    def __init__(self, llm, max_replan=3):
        self.llm = llm
        self.max_replan = max_replan
        self.current_plan = None
    def create_plan(self, goal: Goal, context: Context) -> Plan:
        plan = self.llm.generate_plan(
            goal=goal,
            context=context,
            available_tools=context.tool_registry,
            constraints=context.constraints
        )
        plan.validate()
        self.current_plan = plan
        return plan
    def replan(self, failed_step: Step, error: Error) -> Plan:
        return self.llm.replan(
            original_plan=self.current_plan,
            failed_step=failed_step,
            error=error,
            completed_steps=self.current_plan.completed
        )
    def adaptive_step(self, step: Step) -> Step:
        current_state = self.perceive_environment()
        if self.should_modify_step(step, current_state):
            return self.llm.modify_step(step, current_state)
        return step

2.4 Key Metrics

Planning success rate > 80 % (percentage of plans fully executed)

Re‑planning count < 2 (average number of replans per task)

Step efficiency < 1.5× (actual steps vs. optimal steps)

Context utilization > 90 % (how well the plan uses existing information)

2.5 Common Pitfalls

Planning hallucination : generating nonexistent APIs or tools. Fix: validate tool availability after plan generation.

Over‑planning : turning a 10‑step job into 30 steps. Fix: cap maximum steps and encourage concise plans.

Rigid plans : failure to adapt when a step fails. Fix: implement progressive replanning instead of full rebuild.

Context window overflow : long plans exceed model context. Fix: hierarchical compression, keep only current layer + summary.

Layer 3 – Tools (Agent’s "Hands")

3.1 What the Tool Layer Does

The tool layer is the interface between the agent and the external world. Without tools the LLM can only talk; with tools it can act.

Tools turn language ability into operational ability.

3.2 Tool Classification

Tool Layer
├── Data Retrieval Tools
│   ├── Web Search
│   ├── API Call (REST/GraphQL)
│   ├── Database Query (SQL/NoSQL)
│   └── File Read (PDF/Excel/CSV)
├── Action Execution Tools
│   ├── Code Execution (Python/Shell/SQL)
│   ├── Browser Automation (click, input, navigate)
│   ├── File Operations (create, edit, delete)
│   └── System Operations (process management, network requests)
├── Generation Tools
│   ├── Text Generation (email, report, code)
│   ├── Image Generation (DALL‑E, Stable Diffusion)
│   └── Data Visualization (charts, dashboards)
└── Communication Tools
    ├── Message Sending (Email, Slack, WeChat)
    ├── Notification Push (Webhook, SMS)
    └── Collaboration (Jira, GitHub, Notion)

3.3 Tool Registration & Discovery

Modern agent frameworks treat tools as hot‑plug components. The core pattern is a ToolRegistry that stores tool descriptors and performs semantic search.

class ToolRegistry:
    def __init__(self):
        self.tools: dict[str, Tool] = {}
    def register(self, tool: Tool):
        self.tools[tool.name] = tool
        tool.description = self._generate_description(tool)
    def get_relevant_tools(self, task: str) -> list[Tool]:
        task_embedding = embed(task)
        scored = []
        for tool in self.tools.values():
            score = cosine_sim(task_embedding, embed(tool.description))
            scored.append((score, tool))
        return [t for s, t in sorted(scored, reverse=True)[:5]]
    def validate_call(self, tool_name: str, params: dict) -> bool:
        tool = self.tools[tool_name]
        return tool.schema.validate(params)

class WebSearchTool(Tool):
    name = "web_search"
    description = "Search the internet for real‑time information, suitable for news, data, documents, etc."
    schema = {
        "query": {"type": "string", "required": True},
        "num_results": {"type": "integer", "default": 5, "max": 20},
        "date_range": {"type": "string", "enum": ["day", "week", "month", "year"]}
    }
    def execute(self, query: str, num_results=5, date_range=None):
        results = search_engine.search(query, num_results, date_range)
        return ToolResult(success=True, data=results, metadata={"source": "web", "count": len(results)})

3.4 MCP Protocol – 2026 Tool Standard

At the end of 2025 Anthropic introduced the Model Context Protocol (MCP), which became the de‑facto standard for tool integration, solving the fragmentation problem across frameworks.

Before MCP:
  LangChain – @tool decorator
  AutoGPT – JSON Schema
  Each vendor – own format
After MCP:
  Server provides tool description + execution endpoint
  Client discovers and calls tools dynamically
  Transport: stdio / HTTP SSE / WebSocket

The core benefits of MCP are:

Tool discovery : agents can find available tools without hard‑coding.

Type safety : strict JSON Schema guarantees correct parameters.

Context management : tools declare their context requirements.

Permission control : tools declare required permission levels; high‑risk actions need human confirmation.

3.5 Engineering Principles for Tools

Least privilege : grant only the permissions needed for a task.

Idempotency : repeated calls should not cause side effects, essential for retry logic.

Timeout & circuit‑breaker – every call is wrapped with a timeout and a circuit‑breaker to avoid hanging or cascading failures.

class ToolCallWithProtection:
    def call(self, tool, params, timeout=30):
        try:
            with Timeout(timeout):
                result = tool.execute(**params)
            if self.circuit_breaker.is_open(tool.name):
                return ToolResult(success=False, error="Circuit open")
            return result
        except TimeoutError:
            self.circuit_breaker.record_failure(tool.name)
            return ToolResult(success=False, error=f"Timeout after {timeout}s")
        except Exception as e:
            self.circuit_breaker.record_failure(tool.name)
            return ToolResult(success=False, error=str(e))

Layer 4 – Memory (Agent’s "Hippocampus")

4.1 What the Memory Layer Does

The memory layer enables the agent to:

Remember short‑term context for the current task.

Recall long‑term knowledge such as user preferences and world facts.

Learn from past successes and failures (experience memory).

Without memory, an agent behaves like a fresh intern for every interaction.

4.2 Three‑Tier Memory Architecture

┌─────────────────────────────────────┐
│          Working Memory               │
│  Current task context + recent dialogue│
│  Capacity: limited by model context    │
│  Lifetime: single task                │
├─────────────────────────────────────┤
│          Short‑Term Memory            │
│  Recent interaction history + session│
│  Capacity: last N rounds / K tasks    │
│  Lifetime: across rounds, not sessions│
├─────────────────────────────────────┤
│          Long‑Term Memory             │
│  User preferences + world knowledge   │
│  Capacity: theoretically unlimited (vector DB)│
│  Lifetime: permanent                  │
└─────────────────────────────────────┘

4.3 Working‑Memory Management

Even the largest 2026 model (Gemini 2.5 Ultra) has a 2 M‑token context window. The agent must manage this window with sliding‑window + summarization.

class WorkingMemory:
    def __init__(self, max_tokens: int = 128000):
        self.max_tokens = max_tokens
        self.messages: list[Message] = []
        self.compressor = ContextCompressor()
    def add(self, message: Message):
        self.messages.append(message)
        if count_tokens(self.messages) > self.max_tokens * 0.8:
            self._compress()
    def _compress(self):
        system_prompt = self.messages[0]
        recent = self.messages[-10:]
        old = self.messages[1:-10]
        summary = self.compressor.compress(old)
        self.messages = [system_prompt, Message(role="system", content=f"[History Summary] {summary}"), *recent]
    def get_context(self) -> list[Message]:
        return self.messages

4.4 Long‑Term Vector Memory

class LongTermMemory:
    def __init__(self, embedding_model, vector_db):
        self.embedding_model = embedding_model
        self.vector_db = vector_db  # e.g., ChromaDB, Pinecone, Milvus
    def store(self, content: str, metadata: dict = None):
        embedding = self.embedding_model.encode(content)
        self.vector_db.upsert(
            id=generate_id(content),
            embedding=embedding,
            content=content,
            metadata={**(metadata or {}), "timestamp": now(), "importance": self._score_importance(content)}
        )
    def recall(self, query: str, top_k: int = 5) -> list[Memory]:
        query_embedding = self.embedding_model.encode(query)
        results = self.vector_db.search(embedding=query_embedding, top_k=top_k, filter={"importance": {"$gte": 0.5}})
        return self._deduplicate_and_rank(results)
    def forget(self, memory_id: str):
        self.vector_db.delete(memory_id)

4.5 Experience Memory (Learning from Errors)

class ExperienceMemory:
    def record_success(self, task: Task, plan: Plan, execution: Execution):
        self.store({
            "type": "success",
            "task_signature": task.fingerprint(),
            "plan_steps": [s.description for s in plan.steps],
            "tools_used": execution.tools_used,
            "total_time": execution.duration,
            "outcome": execution.result
        })
    def record_failure(self, task: Task, plan: Plan, error: Error):
        self.store({
            "type": "failure",
            "task_signature": task.fingerprint(),
            "failed_at": error.step_index,
            "error_type": error.type,
            "error_detail": error.message,
            "lesson": self._extract_lesson(error)
        })
    def retrieve_similar_experiences(self, task: Task) -> list[Experience]:
        similar = self.search(task.fingerprint(), top_k=5)
        return sorted(similar, key=lambda e: (e.type == "failure", e.relevance))

4.6 Practical Scoring & Forgetting

Not every piece of information deserves storage. The article proposes a weighted scoring system (user‑explicit mention 0.4, task relevance 0.3, novelty 0.2, recency 0.1). Forgetting mechanisms include time‑decay, conflict overwrite, and explicit user‑initiated purge.

Layer 5 – Execution (Agent’s "Muscles")

5.1 What the Execution Layer Does

The execution layer bridges thought and action. Its responsibilities are to translate plan steps into concrete tool calls, manage concurrency and dependencies, and handle exceptions with retry logic.

5.2 Core Execution Engine Architecture

class ExecutionEngine:
    """Agent execution engine"""
    def __init__(self, tool_registry, memory, max_concurrent=5):
        self.tool_registry = tool_registry
        self.memory = memory
        self.semaphore = asyncio.Semaphore(max_concurrent)
    async def execute_plan(self, plan: Plan) -> ExecutionResult:
        results = []
        for step in plan.steps:
            if step.depends_on:
                for dep in step.depends_on:
                    if not results[dep].success:
                        return ExecutionResult(success=False, failed_at=step.index, needs_replan=True)
            result = await self.execute_step(step)
            results.append(result)
            if not result.success:
                self.memory.record_failure(plan.task, plan, result.error)
        return ExecutionResult(success=True, results=results)
    async def execute_step(self, step: Step) -> StepResult:
        async with self.semaphore:
            tool = self.tool_registry.get(step.tool_name)
            for attempt in range(step.max_retries + 1):
                try:
                    result = await asyncio.wait_for(tool.execute(**step.params), timeout=step.timeout)
                    if self._validate_result(result, step.expected_output):
                        return StepResult(success=True, data=result)
                    if attempt < step.max_retries:
                        step.params = self._adjust_params(step, result)
                        continue
                except asyncio.TimeoutError:
                    if attempt == step.max_retries:
                        return StepResult(success=False, error=TimeoutError(f"Step timed out after {step.timeout}s"))
                except Exception as e:
                    if attempt == step.max_retries:
                        return StepResult(success=False, error=e)
        return StepResult(success=False, error=MaxRetriesExceeded())

5.3 Execution Modes

Serial execution : simple, respects strict dependencies.

Parallel execution : independent steps run concurrently, boosting throughput.

Streaming execution : produce partial results as they become available, useful for long‑running tasks.

5.4 Safety Mechanisms

Sandboxed code execution – Run user‑provided code inside a Docker container with limited resources and network disabled.

class SandboxedCodeExecutor:
    def __init__(self):
        self.container = DockerContainer(
            image="python:3.12-slim",
            memory_limit="512m",
            cpu_limit=1.0,
            network="none",
            timeout=30,
            read_only=True
        )
    def execute(self, code: str) -> ExecutionResult:
        if self._contains_dangerous_ops(code):
            return ExecutionResult(success=False, error="Dangerous operation blocked")
        result = self.container.run(code)
        if len(result.stdout) > 100000:
            result.stdout = result.stdout[:100000] + "...[truncated]"
        return result

Human‑in‑the‑Loop gating – High‑risk actions (delete, financial, irreversible) require explicit human approval.

RISK_LEVELS = {
    "read": 0,
    "create": 1,
    "modify": 2,
    "delete": 3,
    "financial": 4,
    "irreversible": 5
}
class HumanGate:
    def should_confirm(self, action: Action) -> bool:
        return RISK_LEVELS.get(action.risk_type, 5) >= 3
    async def request_confirmation(self, action: Action) -> bool:
        if not self.should_confirm(action):
            return True
        confirmation = await self.notify_human(
            title=f"⚠️ Confirm execution: {action.description}",
            detail=action.details,
            risk_level=action.risk_type,
            timeout=300
        )
        return confirmation.approved

Layer 6 – Feedback (Agent’s "Pain" and Learning)

6.1 What the Feedback Layer Does

Feedback is the engine of evolution. Without it, an agent remains static. The layer aggregates three feedback sources:

Environmental feedback : tool return values (e.g., API 200 vs 500).

Self‑feedback : the agent’s own assessment (e.g., "Did the generated code pass tests?").

Human feedback : explicit user ratings.

6.2 Self‑Reflection Mechanism

class SelfReflection:
    def reflect(self, step: Step, result: StepResult) -> Reflection:
        is_valid = self._validate_output(result)
        goal_progress = self._assess_goal_progress(step.goal, result)
        is_consistent = self._check_consistency(result, self.memory.get_context())
        anomalies = self._detect_anomalies(result)
        reflection = Reflection(
            is_valid=is_valid,
            goal_progress=goal_progress,
            is_consistent=is_consistent,
            anomalies=anomalies,
            action=self._decide_action(is_valid, goal_progress, anomalies)
        )
        return reflection
    def _decide_action(self, is_valid, progress, anomalies) -> str:
        if not is_valid:
            return "retry"
        if anomalies:
            return "investigate"
        if progress < 0:
            return "replan"
        return "continue"

6.3 Learning from Feedback

In‑Context Learning : after a step, the agent injects the reflection into working memory so subsequent steps can use the lesson.

class InContextLearner:
    def update_context(self, feedback: Feedback):
        lesson = self._extract_lesson(feedback)
        self.memory.add(Message(
            role="system",
            content=f"[Lesson] {lesson}",
            priority="high"
        ))

Experience Replay (Offline Learning) : periodically review recent execution logs, cluster failure patterns, and synthesize reusable rules.

class ExperienceReplay:
    def __init__(self, experience_db):
        self.db = experience_db
    def periodic_review(self):
        recent = self.db.get_recent(days=7)
        failure_patterns = self._cluster_failures(recent.failures)
        rules = []
        for pattern in failure_patterns:
            if pattern.frequency >= 3:
                rules.append(self._extract_rule(pattern))
        for rule in rules:
            self._update_behavior_policy(rule)
    def _extract_rule(self, pattern) -> Rule:
        return Rule(
            condition=pattern.trigger_conditions,
            action=pattern.recommended_action,
            confidence=pattern.frequency / pattern.total_occurrences
        )

6.4 Feedback‑Driven Self‑Evolution

Cutting‑edge 2026 research focuses on agents that continuously improve:

Reflexion : after a failure, the agent writes a natural‑language reflection note for future reference.

Self‑Play : two agent instances evaluate each other; one proposes a solution, the other critiques it.

Trajectory Optimization : record full execution trajectories and apply reinforcement learning to reinforce successful paths and suppress failures.

6.5 Feedback Loop Implementation

class FeedbackLoop:
    """Full feedback processing pipeline"""
    def __init__(self):
        self.self_reflection = SelfReflection()
        self.experience_memory = ExperienceMemory()
        self.learner = InContextLearner()
    def process_feedback(self, step: Step, result: StepResult) -> NextAction:
        reflection = self.self_reflection.reflect(step, result)
        if result.success:
            self.experience_memory.record_success(step, result)
        else:
            self.experience_memory.record_failure(step, result.error)
        self.learner.update_context(reflection)
        match reflection.action:
            case "continue":
                return NextAction.CONTINUE
            case "retry":
                return NextAction.RETRY(step, max_retries=2)
            case "replan":
                return NextAction.REPLAN(failed_step=step)
            case "investigate":
                return NextAction.DEBUG(step, reflection.anomalies)
            case "abort":
                return NextAction.ABORT(reason=reflection.summary)
            case "ask_human":
                return NextAction.HUMAN_ESCALATION(step, reflection)

Full 6‑Layer Collaboration – End‑to‑End Example

Task: "Analyze the star‑growth trend of our GitHub repos over the past week and send a report to Slack."

# Perception
intent = data_analysis + report_generation + messaging
entities = {"target": "GitHub repo", "time": "last 7 days", "metric": "star growth", "output": "Slack"}
missing_info = {"specific_repo_names"}
→ ask clarification: "Which repositories?"
→ user replies: "Our three open‑source projects"
→ retrieve from memory the three repo names

# Planning
Plan:
  Step 1: Fetch star history for the three repos (parallel)
  Step 2: Compute growth rates
  Step 3: Generate visual charts
  Step 4: Draft analysis report
  Step 5: Send to Slack #analytics

# Tools
- github_api.get_stargazers(repo, since, until)
- python_executor.run(analysis_code)
- chart_generator.create(data, type="line")
- slack_api.send_message(channel, text, attachments)

# Memory
- Working memory: current dialogue
- Long‑term memory: user's three repo names, Slack channel preference
- Experience memory: previous report format

# Execution
Step 1 → parallel GitHub API calls → ✅
Step 2 → Python analysis → ✅
Step 3 → Chart generation → ✅
Step 4 → Report generation (800 words) → ✅
Step 5 → Slack send → requires human confirmation (risk = 2)
→ human approves → ✅

# Feedback
- Env feedback: Slack API 200 OK
- Self feedback: report covers all repos, data complete
- User feedback: "Report is clear, add fork data next time"
→ record experience: "Add fork growth data in future analyses"

Practical Guidance – Building Your Own Agent

A minimal viable agent can be assembled in one day by implementing perception and execution. Over the following weeks, add tools, planning, memory, and finally feedback. The article lists five deployment principles: start with a single tool, keep a human in the loop, log everything, increase autonomy gradually, and drive development with continuous evaluation.

Technology Stack Recommendations (2026)

Perception: GPT‑5.5 / Claude Opus 4 for intent and entity extraction.

Planning: LangGraph or CrewAI for visual multi‑step orchestration.

Tools: MCP Protocol for standardized tool integration.

Memory: ChromaDB + Redis for vector search and caching.

Execution: Temporal or Celery for task orchestration and retries.

Feedback: Weights & Biases plus custom logging for traceability.

Conclusion

A functional AI agent is not merely a large model with a tool call; it is a complete 6‑layer system where each layer—Perception, Planning, Tools, Memory, Execution, and Feedback—must work together. Missing any layer yields only a demo, not a product. In 2026 the competitive edge lies in system completeness rather than model size.

References:

"A Technical Taxonomy of LLM Agent Communication Protocols" (2026‑06)

"Hierarchical Control in Multi‑Agent Games" (2026‑06)

"Distributed General‑Purpose Agent Networks: Architecture and Prototypes" (2026‑06)

"XFlow: Executable Protocol Programming for Multi‑Agent Workflows" (2026‑06)

"Silent Failure in LLM Agent Systems: The Entropy Principle" (2026‑06)

"Recursive Agent Harnesses" (2026‑06)

"Compositional Skill Routing for LLM Agents" (2026‑06)

MCP Specification v1.0, Anthropic (2025)