[{"data":1,"prerenderedAt":973},["ShallowReactive",2],{"docs-nav":3,"docs-article-agents\u002Fconcepts\u002Fchat-agent-design-principles":516},[4,17,27,44,55,67,75,82,94,106,114,122,129,135,144,153,161,169,177,189,201,211,218,227,235,244,251,258,265,272,277,289,304,314,326,335,340,347,355,361,369,376,383,392,397,405,412,420,425,431,443,453,463,470,476,484,494,501,510],{"path":5,"title":6,"description":7,"group":8,"section":6,"order":9,"tags":10,"lastUpdated":16},"\u002Fagents\u002Fagentic-crm","Agentic CRM","Research brief and build plan for an AgencyCore agentic CRM layer, rendered as an interactive page — the core operating loop, the target architecture, the typed-tool risk gateway, the proposed-actions review queue, and the four-slice MVP.","Agents",0,[11,12,13,14,15],"crm","agents","ai","architecture","research","2026-06-12",{"path":18,"title":19,"description":20,"group":8,"section":21,"order":22,"tags":23,"lastUpdated":26},"\u002Fagents\u002Fchat","Chat agent","High-level system design of the AgencyCore chat agent — core components, data flow, and the two abstractions that hold it together.","Reference",1,[12,14,24,25],"chat","system-design","2026-05-13",{"path":28,"title":29,"description":30,"group":8,"section":31,"order":32,"tags":33,"lastUpdated":43},"\u002Fagents\u002Fcompany-enrichment","Company Enrichment","The company enrichment workflow - a cache-first read in front of the company intelligence database that fills firmographic, contact and technographic facts via a fixed-order provider waterfall, and writes every resolved fact back with provenance so the first org pays once and every later search rides free.","Enrichment",2,[12,34,35,36,37,38,39,40,41,42],"workflow","enrichment","companies","waterfall","cache","intelligence-database","firmographics","provenance","sonar","2026-06-10",{"path":45,"title":46,"description":47,"group":8,"section":48,"order":9,"tags":49,"lastUpdated":54},"\u002Fagents\u002Fcompany-sonar","Company Signals","Signal-first company discovery for marketing agencies, on the Claude Agent SDK, with a global intelligence cache and deterministic composite scoring.","Company Sonar",[12,34,42,50,51,52,35,53,14],"company-search","signals","agent-sdk","scoring","2026-06-08",{"path":56,"title":57,"description":58,"group":8,"section":48,"order":22,"tags":59,"lastUpdated":66},"\u002Fagents\u002Fcompany-sonar\u002Fsignal-monitoring","Company Signals Monitoring","Realtime signal capture layer on top of the data graph. Detects hot events, scores them with a Claude managed agent against each agency's ICP, fans out alerts.",[14,51,60,61,62,63,64,65],"intel","icp","alerts","monitoring","sse","managed-agents","2026-06-09",{"path":68,"title":69,"description":70,"group":8,"section":71,"order":22,"tags":72,"lastUpdated":74},"\u002Fagents\u002Fconcepts\u002Fchat-agent-design-principles","Designing chat agents","The 2026 playbook for production chat agents that reach into internal systems via tools — context engineering, memory, tool design, when to add complexity.","Concepts",[12,14,24,73],"context-engineering","2026-05-14",{"path":76,"title":77,"description":78,"group":8,"section":71,"order":32,"tags":79,"lastUpdated":74},"\u002Fagents\u002Fconcepts\u002Fsystem-prompt-architecture","System prompt architecture","How to structure a production chat agent system prompt — eight sections, what each one does, and the rules vendors converge on.",[12,80,81],"prompt-engineering","system-prompt",{"path":83,"title":84,"description":85,"group":8,"section":84,"order":9,"tags":86,"lastUpdated":54},"\u002Fagents\u002Fenvoy","Envoy","High-level system design for the AI outreach engine — the sequence step state machine, the human-in-the-loop draft approval gate, multi-source context enrichment, and the inbox sentiment flow, rendered as an interactive page.",[12,87,88,89,90,91,92,93,14],"envoy","outreach","sales-engagement","sequences","state-machine","human-in-the-loop","nylas",{"path":95,"title":96,"description":97,"group":8,"section":98,"order":9,"tags":99,"lastUpdated":16},"\u002Fagents\u002Fheadhunter","Headhunter","The AI talent-search pipeline on one page - the production six-step design with its current-title relevance gate, and the 2.0 system design with internal-first waterfall sourcing, a pluggable source registry, automatic entity resolution, and a people intelligence graph that compounds every run.","General Search",[12,34,100,101,14,25,102,37,103,104,105],"headhunter","recruiting","multi-source","entity-resolution","people-intelligence","flywheel",{"path":107,"title":108,"description":109,"group":8,"section":21,"order":32,"tags":110,"lastUpdated":113},"\u002Fagents\u002Fpaperclip","Paperclip","Architecture deep dive into the Paperclip orchestration system.",[12,14,111,112],"orchestration","paperclip","2026-04-20",{"path":115,"title":116,"description":117,"group":8,"section":31,"order":22,"tags":118,"lastUpdated":16},"\u002Fagents\u002Fpeople-enrichment","People Enrichment","The people enrichment workflow - a cache-first read in front of the people intelligence database that fills profile, contact and employment facts via a fixed-order provider waterfall, keyed on the LinkedIn URL, and writes every resolved fact back with provenance so the first org pays once and every later search rides free. The fill step Headhunter and People Signals both call.",[12,34,35,119,37,38,39,120,41,100,121],"people","linkedin","people-sonar",{"path":123,"title":124,"description":125,"group":8,"section":126,"order":9,"tags":127,"lastUpdated":54},"\u002Fagents\u002Fpeople-sonar","People Signals","Signal-first people discovery for marketing agencies, built on the headhunter pipeline, with a composite score weighted by signal strength, source reputation, recency, and ICP fit.","People Sonar",[12,34,121,128,51,100,35,53,14],"people-search",{"path":130,"title":131,"description":132,"group":8,"section":126,"order":22,"tags":133,"lastUpdated":54},"\u002Fagents\u002Fpeople-sonar\u002Fpeople-signal-monitoring","People Signals Monitoring","Forward-looking design for the push layer that tracks known people - champions, past contacts, target-company decision-makers - and fires a warm lead the moment they change jobs, get promoted, or their company has an event.",[14,51,60,119,63,134],"warm-leads",{"path":136,"title":137,"description":138,"group":139,"section":140,"order":22,"tags":141,"lastUpdated":143},"\u002Fengineering\u002Fguides\u002Fagent-execution-stack","The Agent Execution Stack","Durable workflows over pluggable agent backends — how AgencyCore runs AI agents on Inngest over a webhook-driven Claude Managed Agents backend.","Engineering","Guides",[12,142,14,25],"inngest","2026-06-25",{"path":145,"title":146,"description":147,"group":139,"section":140,"order":9,"tags":148,"lastUpdated":143},"\u002Fengineering\u002Fguides\u002Fagent-runtime","Agent runtime","How AgencyCore runs AI agents on a provider-neutral runtime — the abstraction layer that lets us swap the agent backend, with Claude managed agents as the current provider.",[12,149,14,150,151,152,25],"runtime","anthropic","claude","providers",{"path":154,"title":155,"description":156,"group":139,"section":21,"order":157,"tags":158,"lastUpdated":160},"\u002Fengineering\u002Freference\u002Fagno-to-agent-sdk-migration","Agno → Claude Agent SDK migration","System-design spec for moving the ac-python-api workflow engine off Agno onto Anthropic's Claude Agent SDK \u002F Managed Agents, tiered by control-flow shape.",10,[12,14,159,52,65],"migration","2026-06-06",{"path":162,"title":163,"description":164,"group":139,"section":21,"order":22,"tags":165,"lastUpdated":54},"\u002Fengineering\u002Freference\u002Fcloudflare-agent-sandbox","Cloudflare agent sandbox","Cloudflare's Workers-based agent platform, evaluated as an alternative sandbox for our Agno workflows.",[12,166,167,168,159],"sandbox","cloudflare","workers",{"path":170,"title":171,"description":172,"group":139,"section":21,"order":32,"tags":173,"lastUpdated":176},"\u002Fengineering\u002Freference\u002Fvirtual-filesystem-rag","Virtual filesystem for AI assistants","How ChromaFs provides AI agents with structured file access.",[12,174,14,175],"rag","chromafs","2026-04-18",{"path":178,"title":179,"description":180,"group":181,"section":182,"order":183,"tags":184,"lastUpdated":66},"\u002Flearnings\u002Fagentic-sdlc","The agentic SDLC","How AI agents move from autocomplete to owning the loop across the software lifecycle, and why that shifts the bottleneck from coding to verification.","Learnings",null,30,[12,185,186,187,188],"sdlc","engineering","verification","review",{"path":190,"title":191,"description":192,"group":181,"section":182,"order":193,"tags":194,"lastUpdated":200},"\u002Flearnings\u002Fagi-to-asi","From AGI to ASI","What lies beyond human-level AI. The four technological pathways from AGI to artificial superintelligence, the formal ceiling that bounds them, and the six bottlenecks that could stall the climb - distilled from the DeepMind report.",50,[195,196,197,198,199],"ai-futures","asi","agi","scaling","recursive-self-improvement","2026-06-19",{"path":202,"title":203,"description":204,"group":181,"section":182,"order":205,"tags":206,"lastUpdated":66},"\u002Flearnings\u002Fai-native-company-playbook","AI native company playbook","Why AI should be the operating system your company runs on, not a tool it uses, and the concrete practices that follow - closed loops, a queryable org, software factories, and token maxing.",40,[207,208,12,209,210],"ai-native","company-building","gtm","founders",{"path":212,"title":213,"description":214,"group":181,"section":182,"order":157,"tags":215,"lastUpdated":54},"\u002Flearnings\u002Fbuying-intent-signals","Buying intent signals","How buyers leak their intent before they ever fill in a form, and how to read those signals before the window closes.",[216,51,209,217],"intent","sales",{"path":219,"title":220,"description":221,"group":181,"section":182,"order":222,"tags":223,"lastUpdated":54},"\u002Flearnings\u002Fcold-outbound-system","Cold outbound system","A high-level study of an open-source 29-skill cold email system, organized into five sequential tracks from ICP to iteration.",20,[224,225,209,226],"outbound","cold-email","systems",{"path":228,"title":229,"description":230,"group":181,"section":182,"order":231,"tags":232,"lastUpdated":234},"\u002Flearnings\u002Fswan-gtm-skills-architecture","Swan GTM skills architecture","A research note on Swan AI's foundations and maps model for GTM agents, with ASCII diagrams and ideas AgencyCore can borrow.",60,[209,12,73,233,14],"swan","2026-07-01",{"path":236,"title":237,"description":238,"group":239,"section":182,"order":240,"tags":241,"lastUpdated":43},"\u002Fmission-control\u002Fciops-agent","CIOps agent","High-level system architecture and design notes for the Mission Control CIOps agent.","Mission Control",14,[242,12,243,14],"mission-control","ciops",{"path":245,"title":246,"description":247,"group":239,"section":182,"order":248,"tags":249,"lastUpdated":43},"\u002Fmission-control\u002Fcostops-agent","CostOps agent","High-level system architecture and design notes for the Mission Control CostOps agent.",11,[242,12,250,14],"finops",{"path":252,"title":253,"description":254,"group":239,"section":182,"order":222,"tags":255,"lastUpdated":54},"\u002Fmission-control\u002Fdashboard","Dashboard","The Mission Control product UI - a dark cockpit with a fleet-nav rail, company-state grid, a working escalation queue, live ledger and a global kill switch.",[242,12,256,257],"dashboard","ui",{"path":259,"title":260,"description":261,"group":239,"section":182,"order":262,"tags":263,"lastUpdated":43},"\u002Fmission-control\u002Fproduct-analytics-agent","ProductAnalytics agent","High-level system architecture and design notes for the Mission Control ProductAnalytics agent.",13,[242,12,264,14],"product-analytics",{"path":266,"title":267,"description":268,"group":239,"section":182,"order":269,"tags":270,"lastUpdated":43},"\u002Fmission-control\u002Frevenueops-agent","RevenueOps agent","High-level system architecture and design notes for the Mission Control RevenueOps agent.",12,[242,12,271,14],"revops",{"path":273,"title":274,"description":275,"group":239,"section":182,"order":157,"tags":276,"lastUpdated":54},"\u002Fmission-control\u002Fsystem-design","System design","One screen for the whole company, watched by a guardrailed fleet of ops agents that explain, propose, act and learn overnight.",[242,12,250,14],{"path":278,"title":279,"description":280,"group":281,"section":182,"order":32,"tags":282,"lastUpdated":288},"\u002Fproduct-design\u002Fonboarding-flow","Onboarding flow","Product design for the signup wizard and how TAM building folds into it. Analyzes the flow today (account, profile, company), the gap (no ICP, empty dashboard), and the integration of a new \"who you sell to\" ICP step plus a build-and-reveal screen that lands the user on a populated, ranked list.","Product Design",[283,61,284,285,286,287],"onboarding","tam","activation","ux","user-journey","2026-06-11",{"path":290,"title":291,"description":292,"group":281,"section":182,"order":293,"tags":294,"lastUpdated":303},"\u002Fproduct-design\u002Fpricing-entitlements","Pricing tiers, entitlements and usage credits","Specification for subscription tiers with gated platform access: composable plan entitlements, a unified usage-credit currency, plan-sourced limits, per-module trials and a two-ticket delivery plan built on the Stripe billing foundation. Written for discussion; the Linear document is the canonical copy with ticket links.",3,[295,296,297,298,299,300,301,302],"pricing","entitlements","billing","credits","subscriptions","plans","seats","trials","2026-07-06",{"path":305,"title":306,"description":307,"group":281,"section":182,"order":293,"tags":308,"lastUpdated":288},"\u002Fproduct-design\u002Fsales-signals-ux","Designing Signals","Product design for the sales-signals experience in ac-frontend: the 14-type taxonomy and its color system, the anatomy of a signal card across four densities, the 0-10 lead score scale, the origin tag (sonar pull vs proactive push), the seven surfaces where signals render (launchpad, sonar app, company detail, timeline, activities, data layer, Envoy), and the interaction rules that keep them consistent.",[51,286,309,11,42,310,311,312,313],"design-system","lead-score","origin","pull","push",{"path":315,"title":316,"description":317,"group":318,"section":319,"order":320,"tags":321,"lastUpdated":43},"\u002Fproprietary-data\u002Fcrm\u002Factivities","Activities","Deep dive on crm_activities, the interaction + task log of the CRM — where it is served from, how a row is born and read, and its full schema, relationships and rules.","Proprietary data","CRM",4,[11,322,323,324,325],"activities","tasks","data-model","schema",{"path":327,"title":328,"description":329,"group":318,"section":319,"order":330,"tags":331,"lastUpdated":43},"\u002Fproprietary-data\u002Fcrm\u002Fcommunications","Communications","Deep dive on crm_communications and crm_communication_events, the unified email\u002Fcall\u002Fmessage log and its per-message engagement tracking — where it is served from, the outbound message lifecycle, and the full schema, relationships and rules.",5,[11,332,333,334,324],"communications","email","engagement",{"path":336,"title":337,"description":338,"group":318,"section":319,"order":22,"tags":339,"lastUpdated":43},"\u002Fproprietary-data\u002Fcrm\u002Fcompanies","Companies","Deep dive on crm_companies, the account record at the centre of the CRM — where it is served from, how a row is born and read, and its full schema, relationships and rules.",[11,36,324,325,14],{"path":341,"title":342,"description":343,"group":318,"section":319,"order":293,"tags":344,"lastUpdated":43},"\u002Fproprietary-data\u002Fcrm\u002Fdeals","Deals","Deep dive on the deal pipeline — crm_deals, crm_pipeline_stages and crm_pipeline_config. Where it is served from, the life of a deal, and its full schema, relationships and rules.",[11,345,346,324,325],"deals","pipeline",{"path":348,"title":349,"description":350,"group":318,"section":319,"order":351,"tags":352,"lastUpdated":43},"\u002Fproprietary-data\u002Fcrm\u002Flists","Lists","Deep dive on crm_lists and crm_list_members, the static or dynamic member collections of the CRM — where they are served from, how a list and its members come to be and are read, and their schema, relationships and rules.",6,[11,353,354,324,325],"lists","segments",{"path":356,"title":357,"description":358,"group":318,"section":319,"order":32,"tags":359,"lastUpdated":43},"\u002Fproprietary-data\u002Fcrm\u002Fpeople","People","Deep dive on crm_people, the contact record of the CRM — where it is served from, how a row is born and read, and its full schema, relationships and rules.",[11,119,360,324,325],"contacts",{"path":362,"title":363,"description":364,"group":318,"section":319,"order":365,"tags":366,"lastUpdated":43},"\u002Fproprietary-data\u002Fcrm\u002Fsaved-filters","Saved filters","Deep dive on crm_saved_filters, the named reusable filter snapshots over the company, person and signal list views — where it is served from, how a saved view is born and applied, and its full schema, relationships and rules.",8,[11,367,368,324,325],"saved-filters","views",{"path":370,"title":371,"description":372,"group":318,"section":319,"order":373,"tags":374,"lastUpdated":288},"\u002Fproprietary-data\u002Fcrm\u002Fsignals","Signals","Deep dive on the signals tables - signals, company_signals and person_signals, the CRM's sales-intelligence layer. Where signals are served from, how one is born and attached, and the full schema, relationships and rules.",7,[11,51,375,324,325],"intelligence",{"path":377,"title":378,"description":379,"group":318,"section":380,"order":22,"tags":381,"lastUpdated":43},"\u002Fproprietary-data\u002Fintelligence-databases\u002Fcompany-intelligence-database","Company Intelligence Database","Decided architecture for ENG-669, the cross-org company intelligence layer that acts as a read-through cache in front of enrichment providers, with public-facts-only privacy and provenance-tracked write-back.","Intelligence databases",[14,60,36,51,38,382],"eng-669",{"path":384,"title":385,"description":386,"group":318,"section":380,"order":320,"tags":387,"lastUpdated":288},"\u002Fproprietary-data\u002Fintelligence-databases\u002Forg-signal-feed","Org Signal Feed","The per-org activation layer on top of the shared signals store. One immutable intel_signals row fans out to many orgs through scoring (signal-type weight times ICP fit times recency decay) and materializes as ranked, tiered rows in intel_org_signal_feed - the only org-scoped, RLS-per-org table of the signal stack, the door the launchpad, inbox and digest all read through. Signals enter by two ingest classes - a user's sonar pull (ungated) or an automated push (gated by threshold plus an optional competitor-ICP check) - logged in intel_signal_ingests, and each feed row records its origin.",[14,60,51,388,53,389,390,285,391,312,313,311],"feed","decay","rls","ingest",{"path":393,"title":394,"description":395,"group":318,"section":380,"order":32,"tags":396,"lastUpdated":288},"\u002Fproprietary-data\u002Fintelligence-databases\u002Fpeople-intelligence-database","People Intelligence Database","Decided architecture for the cross-org people intelligence layer - a read-through cache in front of headhunter research and Hunter email lookups, with LinkedIn-URL identity, append-only employment edges, per-tier freshness stamps on the flat profile, shared intel_sources provenance, unified intel_signals, and a GDPR erasure path.",[14,60,119,51,38,100],{"path":398,"title":399,"description":400,"group":318,"section":380,"order":293,"tags":401,"lastUpdated":288},"\u002Fproprietary-data\u002Fintelligence-databases\u002Fsignals-intelligence-database","Signals Intelligence Database","Decided v1 architecture for the unified signal store - one polymorphic append-only intel_signals table that holds both company and person signals, with a shared taxonomy, source-ranked provenance, an intel_signal_ingests log that records which pipeline found each signal, decay at read time, and a person-to-company rollup so a champion job change surfaces on the company feed.",[14,60,51,402,389,403,388,404,41,312,313],"polymorphic","taxonomy","ingests",{"path":406,"title":407,"description":408,"group":318,"section":182,"order":9,"tags":409,"lastUpdated":16},"\u002Fproprietary-data\u002Foverview","Data Layer Overview","The AgencyCore data layer in one map - the org-scoped CRM plane in production today and the global intelligence plane designed to sit in front of it, with interactive diagrams of both, the end-to-end data flow, freshness and precedence rules, the privacy seam, and the rollout path.",[410,14,60,11,51,38,25,411],"data-layer","overview",{"path":413,"title":414,"description":415,"group":416,"section":182,"order":9,"tags":417,"lastUpdated":54},"\u002Froadmap","Roadmap - June 2026","June 2026 product plan across four themes. The spine is moving our agents onto an isolated sandbox runtime and rebuilding the core agents and workflows on it, then standing up a read-through intelligence data store and shipping the Stripe billing system. Knowledge base, assistant, and credit tracking carry into the July roadmap.","Roadmap",[418,419],"roadmap","planning",{"path":421,"title":422,"description":423,"group":416,"section":182,"order":22,"tags":424,"lastUpdated":54},"\u002Froadmap\u002Fjuly-2026","Roadmap - July 2026","July 2026 product plan across three themes, all carried over from June. Building on June's sandbox runtime, July grounds the agents in a knowledge base, launches the AI chat assistant, and meters every action with per-action credit tracking that reconciles into the Stripe billing system shipped in June.",[418,419],{"path":426,"title":427,"description":428,"group":416,"section":182,"order":32,"tags":429,"lastUpdated":234},"\u002Froadmap\u002Fjune-2026-slides","Roadmap slides - June 2026","Board-review slide deck for the June 2026 product roadmap, rendered directly from the original PPTX in the docs site.",[418,419,430],"slides",{"path":432,"title":433,"description":434,"group":435,"section":8,"order":222,"tags":436,"lastUpdated":16},"\u002Fsymphony\u002Fagents\u002Fdevops-agent","DevOps agent","Interactive design for a Slack-first Symphony DevOps agent that wraps production promotion, rollback, audit, and operational jobs behind policy gates, typed runbooks, and an auditable ledger.","Symphony",[437,438,439,440,441,442],"symphony","slack","devops","production","runbooks","operations",{"path":444,"title":445,"description":446,"group":435,"section":8,"order":157,"tags":447,"lastUpdated":16},"\u002Fsymphony\u002Fagents\u002Foncall-agent","Oncall agent","Interactive design for a Symphony oncall agent that turns Sentry incidents into rich Linear tickets, investigates with Codex, opens fix PRs, and resolves Sentry after merge.",[437,448,449,450,451,452],"sentry","linear","oncall","incident-response","codex",{"path":454,"title":455,"description":456,"group":435,"section":457,"order":157,"tags":458,"lastUpdated":16},"\u002Fsymphony\u002Fhousekeeping\u002Fcodex-vacuum","Codex vacuum","Interactive design for the Symphony housekeeping timer that checkpoints and vacuums Codex sqlite stores on the VPS.","Housekeeping",[437,459,460,452,461,462],"timed-jobs","housekeeping","sqlite","vps",{"path":464,"title":465,"description":466,"group":435,"section":457,"order":183,"tags":467,"lastUpdated":16},"\u002Fsymphony\u002Fhousekeeping\u002Fhost-cleanup","Host cleanup","Interactive design for the Symphony housekeeping timer that removes stale \u002Ftmp debris, vacuums the journal, and optionally cleans the apt package cache.",[437,459,460,462,468,469],"disk","cleanup",{"path":471,"title":472,"description":473,"group":435,"section":457,"order":222,"tags":474,"lastUpdated":16},"\u002Fsymphony\u002Fhousekeeping\u002Fworkspace-cleanup","Workspace cleanup","Interactive design for the Symphony housekeeping timer that prunes idle per-issue workspaces after their TTL.",[437,459,460,475,469,462],"workspaces",{"path":477,"title":478,"description":479,"group":435,"section":182,"order":9,"tags":480,"lastUpdated":66},"\u002Fsymphony","Symphony orchestration","How AgencyCore runs OpenAI Symphony as a long-running daemon that turns Linear tickets into isolated, autonomous Codex runs, reviewed by Claude and merged by humans. High-level workflow, system architecture, and the engineer playbook.",[437,452,449,481,111,462,482,483],"claude-review","qa","automation",{"path":485,"title":486,"description":487,"group":435,"section":488,"order":205,"tags":489,"lastUpdated":16},"\u002Fsymphony\u002Ftimed-jobs\u002Fdaily-security-agent","Daily security agent","Interactive design for a report-only Symphony timed job that reviews the last 24h of commits, scans the system for vulnerabilities, and opens focused follow-up tickets.","Timed jobs",[437,490,459,452,491,492,493],"security","semgrep","threat-model","ownership",{"path":495,"title":496,"description":497,"group":435,"section":488,"order":183,"tags":498,"lastUpdated":16},"\u002Fsymphony\u002Ftimed-jobs\u002Fdaily-sentry-triage","Daily Sentry triage","Interactive design for the Symphony timed job that performs read-only Sentry triage, deduplicates existing tracked clusters, and creates focused ENG bugs for new actionable errors.",[437,459,448,499,500,449],"observability","triage",{"path":502,"title":503,"description":504,"group":435,"section":488,"order":157,"tags":505,"lastUpdated":16},"\u002Fsymphony\u002Ftimed-jobs\u002Fnightly-local-staging-e2e","Nightly local staging E2E","Interactive design for the Symphony timed job that seeds local Supabase, runs ac-frontend Playwright E2E against the local staging stack, uploads evidence, and cleans artifacts.",[437,459,506,507,508,509],"e2e","playwright","staging","frontend",{"path":511,"title":512,"description":513,"group":435,"section":488,"order":222,"tags":514,"lastUpdated":16},"\u002Fsymphony\u002Ftimed-jobs\u002Fnightly-staging-qa","Nightly staging QA","Interactive design for the Symphony timed job that seeds a staging QA Linear issue, runs an agent-browser crawl, validates feature-map coverage, and files focused follow-up work.",[437,459,508,482,515,449],"agent-browser",{"id":517,"title":69,"body":518,"customComponent":182,"description":70,"extension":963,"group":8,"lastUpdated":74,"meta":964,"navigation":965,"order":22,"path":68,"related":966,"section":71,"seo":969,"stem":970,"tags":971,"__hash__":972},"docs\u002Fagents\u002Fconcepts\u002Fchat-agent-design-principles.md",{"type":519,"value":520,"toc":951},"minimark",[521,525,533,538,546,549,560,563,597,601,604,610,617,621,624,630,663,667,675,682,685,689,692,715,718,721,757,761,772,775,805,812,816,819,822,845,848,852,855,861,868,872,879,882,912,915,919],[522,523,69],"h1",{"id":524},"designing-chat-agents",[526,527,528,529,532],"p",{},"What the broader industry has converged on for building production chat agents that can reach into internal systems via tools. Framework- and vendor-neutral. The AgencyCore-specific shape lives in ",[530,531,19],"a",{"href":18},".",[534,535,537],"h2",{"id":536},"where-the-quality-lives","Where the quality lives",[526,539,540,541,545],{},"Modern chat agents are mostly a loop around one model call, with tools and memory bolted on. That part is easy. What separates a brittle demo from a system you can put in front of customers is ",[542,543,544],"strong",{},"context engineering",": deciding what the model sees on every turn, in what order, and how state survives between turns.",[526,547,548],{},"The dominant 2026 consensus is to treat the prompt as a layered envelope assembled per turn, with a stable cacheable prefix on top and fresh evidence near the user's question.",[550,551,556],"pre",{"className":552,"code":554,"language":555},[553],"language-text","┌─────────────────────────────────────────────────────────────────┐\n│  ┌───────────────────────────────────────────────────────────┐  │\n│  │ 1. System prompt   (stable, cacheable across turns)       │  │\n│  │    identity, scope, tool-use rules, output format          │  │\n│  └───────────────────────────────────────────────────────────┘  │\n│  ┌───────────────────────────────────────────────────────────┐  │\n│  │ 2. Tool definitions   (stable, cacheable)                  │  │\n│  │    name, when to use, args, example call                   │  │\n│  └───────────────────────────────────────────────────────────┘  │\n│  ┌───────────────────────────────────────────────────────────┐  │\n│  │ 3. Persistent context   (slow-changing)                    │  │\n│  │    user role, org glossary, long-term memory summary       │  │\n│  └───────────────────────────────────────────────────────────┘  │\n│  ┌───────────────────────────────────────────────────────────┐  │\n│  │ 4. Session state   (per-conversation)                      │  │\n│  │    rolling summary of older turns + last N raw turns       │  │\n│  └───────────────────────────────────────────────────────────┘  │\n│  ┌───────────────────────────────────────────────────────────┐  │\n│  │ 5. Retrieved evidence   (per-turn, just-in-time)           │  │\n│  │    RAG hits, scoped documents, each tagged with source id  │  │\n│  └───────────────────────────────────────────────────────────┘  │\n│  ┌───────────────────────────────────────────────────────────┐  │\n│  │ 6. Tool results   (current loop iteration only)            │  │\n│  └───────────────────────────────────────────────────────────┘  │\n│  ┌───────────────────────────────────────────────────────────┐  │\n│  │ 7. User message   (closest to generation)                  │  │\n│  └───────────────────────────────────────────────────────────┘  │\n└─────────────────────────────────────────────────────────────────┘\n              ▲                                       ▲\n        cache-friendly                          fresh per turn\n","text",[557,558,554],"code",{"__ignoreMap":559},"",[526,561,562],{},"Five rules carry most of the weight:",[564,565,566,573,579,585,591],"ol",{},[567,568,569,572],"li",{},[542,570,571],{},"Retrieve before you reason, cite before you recommend."," Push this into the system prompt; have tools return source IDs so citations are mechanical.",[567,574,575,578],{},[542,576,577],{},"Keep the cacheable prefix byte-stable."," Sections 1 through 3 must not vary turn to turn. Anything dynamic — page state, today's date, document scope — lives below, otherwise you bust the provider's prompt cache on every message and pay for it on every active conversation.",[567,580,581,584],{},[542,582,583],{},"Summarize old turns, do not truncate."," A rolling summary preserves intent. Hard truncation throws away the user's actual goal.",[567,586,587,590],{},[542,588,589],{},"Scope tools per request."," Surface five tools relevant to the user instead of forty general ones. Fewer tools means fewer wrong tool calls.",[567,592,593,596],{},[542,594,595],{},"Filter tool results before they re-enter context."," Raw API responses are noisy. Map them to compact, schema-stable summaries the model can read as text, not as JSON archaeology.",[534,598,600],{"id":599},"memory-short-term-lives-in-the-window-long-term-lives-outside","Memory: short-term lives in the window, long-term lives outside",[526,602,603],{},"Short-term memory is the prompt itself: recent turns, the rolling summary, the current tool results. Long-term memory is outside the model — a vector store of prior conversations, a KV store of user preferences, an episodic log of past decisions. The agent fetches from long-term memory on demand and pulls the result into short-term context just for this turn.",[550,605,608],{"className":606,"code":607,"language":555},[553],"   ┌──── short-term ────┐         ┌──── long-term (outside model) ────┐\n   │ recent turns       │         │ vector store: prior chats, docs   │\n   │ tool results       │  ◄──►   │ KV store: user prefs, facts       │\n   │ rolling summary    │ fetch   │ episodic log: events, decisions   │\n   │ scratchpad \u002F plan  │         │ skills \u002F SOP library              │\n   └────────────────────┘         └───────────────────────────────────┘\n",[557,609,607],{"__ignoreMap":559},[526,611,612,613,616],{},"Crucially, ",[542,614,615],{},"the rolling summary is short-term but its content is long-lived"," — it represents older turns that have already scrolled out of the live window. The trick is to persist it so the next turn can replay it without re-deriving it from raw history.",[534,618,620],{"id":619},"tool-design","Tool design",[526,622,623],{},"The model reads tool definitions the same way a junior engineer reads an API doc. Treat the docstring as user-facing copy.",[550,625,628],{"className":626,"code":627,"language":555},[553],"       Hostile                       Friendly\n  ┌──────────────┐                ┌──────────────────────┐\n  │ get_data()   │                │ search_customer(     │\n  │   → 4MB JSON │                │   query: str,        │\n  └──────────────┘                │   limit: int = 10    │\n                                  │ ) → [{id,name,plan}] │\n                                  │                      │\n                                  │ # when to use:       │\n                                  │ # finding a customer │\n                                  │ # by free-text       │\n                                  │ # when NOT to use:   │\n                                  │ # listing all-       │\n                                  │ # use search w\u002F      │\n                                  │ # empty query        │\n                                  └──────────────────────┘\n",[557,629,627],{"__ignoreMap":559},[631,632,633,636,650,653,660],"ul",{},[567,634,635],{},"One tool, one verb. Overlapping tools confuse the model more than missing ones limit it.",[567,637,638,639,642,643,646,647,532],{},"Docstrings always include ",[542,640,641],{},"when to use",", ",[542,644,645],{},"when not to use",", and ",[542,648,649],{},"one example call",[567,651,652],{},"Return shapes are stable, small, and human-readable. The model reads them as text.",[567,654,655,656,659],{},"Errors are messages the model can act on (",[557,657,658],{},"\"customer not found, try search_customer with a partial name\"","), not stack traces.",[567,661,662],{},"Compact large results before they re-enter context. The model is reading text, not parsing JSON archaeology.",[534,664,666],{"id":665},"tool-granularity-workflow-shape-not-api-parity","Tool granularity: workflow shape, not API parity",[526,668,669,670,674],{},"Three workflow-shaped tools beat thirty CRUD wrappers. The granularity heuristic is that a tool corresponds to a ",[671,672,673],"em",{},"user intent"," (read this thing, write that thing, read these things in parallel), not to a backend endpoint. A chat agent that has to choose between forty look-alike tools picks the wrong one more often than an agent with five sharply distinct ones, and pays for the full schema list on every turn either way.",[526,676,677,678,681],{},"When parallelism matters, expose it as its own tool. A separate ",[557,679,680],{},"read_many"," beats inviting the model to schedule N sequential single-reads. The model does not enjoy planning fan-out; making it part of the tool surface removes a class of \"called the read tool four times when one batch call would have worked\" bugs.",[526,683,684],{},"When something needs procedural knowledge or many heuristics to use correctly, it's not a tool — it's a skill. See the next section.",[534,686,688],{"id":687},"skills-are-the-layer-below-tools-and-they-progressively-disclose","Skills are the layer below tools, and they progressively disclose",[526,690,691],{},"Tools are functions. Skills are bundles of procedural knowledge that tell the agent how to use those tools well: entity-resolution rules, common patterns, troubleshooting, page-specific behaviour. They live as Markdown files with frontmatter, not as Python.",[526,693,694,695,698,699,702,703,706,707,710,711,714],{},"The load-bearing property is ",[542,696,697],{},"progressive disclosure",". Skill metadata (name + one-line description, ~tens of tokens) loads up front so the model knows which skills exist. The skill body loads on demand when the model decides it needs it. The trigger lives in the system prompt: \"for CRM work, load the ",[557,700,701],{},"ac-cli-crm"," skill\"; \"if ",[557,704,705],{},"Current route:"," matches ",[557,708,709],{},"\u002Flaunchpad",", load the ",[557,712,713],{},"launchpad"," skill\". The skill body never enters context until earned — a fifteen-skill registry costs maybe a kilobyte of metadata.",[526,716,717],{},"This is the dial that makes the cacheable prefix small without sacrificing depth. A 5KB skill body that loads on 1 in 10 turns costs less, on average, than 1KB of trivia that loads on every turn. Treat skill descriptions as the user-facing copy: third-person, \"what + when\", under a kilobyte. The model uses them to choose.",[526,719,720],{},"The pattern decomposes naturally:",[631,722,723,733,744],{},[567,724,725,728,729,732],{},[542,726,727],{},"Shared rules"," (",[557,730,731],{},"ac-cli",") — entity resolution, action bias, output conventions; always loaded once.",[567,734,735,728,738,642,740,743],{},[542,736,737],{},"Domain skills",[557,739,701],{},[557,741,742],{},"ac-cli-envoy",", …) — command names, flags, worked examples; loaded by intent.",[567,745,746,728,749,642,751,642,753,756],{},[542,747,748],{},"Route-aware skills",[557,750,713],{},[557,752,42],{},[557,754,755],{},"current-view",") — page-specific behaviour; loaded when the route matches.",[534,758,760],{"id":759},"error-recovery-is-a-tool-contract-not-the-models-problem","Error recovery is a tool contract, not the model's problem",[526,762,763,764,767,768,771],{},"Tool errors return short, actionable strings the model can act on directly — ",[557,765,766],{},"\"argument X not allowed — reload the domain skill and retry\"",", not stack traces, error codes, or ",[557,769,770],{},"{\"error\": {\"type\": \"...\", \"details\": {...}}}"," archaeology. The agent should be able to retry without a human in the loop.",[526,773,774],{},"Two failure modes deserve explicit handling at the tool layer rather than getting handed to the model raw:",[631,776,777,791],{},[567,778,779,782,783,786,787,790],{},[542,780,781],{},"Empty success."," When the contract says every success carries data and the tool got back nothing, that's a failure — not a ",[557,784,785],{},"Done",". Surface it (",[557,788,789],{},"\"Command produced no output; cannot verify the action succeeded — re-read the entity\"",") so the model re-reads instead of confabulating success.",[567,792,793,796,797,800,801,804],{},[542,794,795],{},"Oversized success."," Compact large payloads server-side before they re-enter context. A single \"list everything\" call should not bloat this turn ",[671,798,799],{},"and"," every subsequent turn via conversation history. Return ",[557,802,803],{},"{summarized: true, total_count: N, preview: [...], note: \"...\"}"," and let the model drill in if it needs to.",[526,806,807,808,811],{},"Treat the tool envelope as a contract the model is allowed to depend on: ",[557,809,810],{},"ok: bool",", stable field names, predictable error semantics. Random shape changes are how silent regressions creep in.",[534,813,815],{"id":814},"cache-stability-is-a-load-bearing-invariant","Cache stability is a load-bearing invariant",[526,817,818],{},"Modern providers cache long input prefixes. A byte-stable prefix on every turn means every active conversation pays the cached-input rate (a fraction of full input); a prefix that drifts means every conversation pays full price every turn. On a chat product this is the difference between a sustainable cost line and one that scales linearly with engagement.",[526,820,821],{},"Two rules buy this property:",[631,823,824,831],{},[567,825,826,827,830],{},"Anything dynamic (page state, today's date, document scope) rides in a ",[542,828,829],{},"per-turn user-message preamble"," below the cached prefix. Never spliced into the system instructions.",[567,832,833,834,837,838,642,841,844],{},"The static prefix (system prompt + tool schemas + skill registry) is ",[542,835,836],{},"pinned in CI",". Hash the rendered system prompt; hash the rendered tool schemas; fail the build on silent drift. Pair the hashes with explicit version constants (",[557,839,840],{},"PROMPT_VERSION",[557,842,843],{},"TOOL_VERSION",") and a bump ceremony: edit → bump version → run snapshot test → paste new digest → re-run until green.",[526,846,847],{},"The ceremony is tedious by design. The cost of skipping it is that an innocent-looking copy edit rotates the cache prefix and every active conversation pays full input price until the cache rewarms. Snapshot tests catch this at PR time instead of in next month's invoice.",[534,849,851],{"id":850},"when-to-add-complexity","When to add complexity",[526,853,854],{},"The temptation with agents is to reach for multi-agent orchestration too early. The honest progression is the other way around:",[550,856,859],{"className":857,"code":858,"language":555},[553]," well-defined  ───────────►  fluid \u002F exploratory\n ┌──────────┐  ┌──────────┐  ┌──────────────┐  ┌──────────────┐\n │  Chain   │  │  Router  │  │ Orchestrator │  │ Agent loop   │\n │ (fixed)  │  │ (branch) │  │ + workers    │  │ (model-led)  │\n └──────────┘  └──────────┘  └──────────────┘  └──────────────┘\n       Workflows (you decide the flow)         Agents (LLM decides)\n",[557,860,858],{"__ignoreMap":559},[526,862,863,864,867],{},"Start with a ",[542,865,866],{},"single agent loop"," behind a streaming chat endpoint. Promote to orchestrator-workers only when a concrete failure mode demands it — usually because one agent's context is mixing concerns it can't handle cleanly. Multi-agent systems multiply the surface area of your bugs by the number of agents; do not pay that cost speculatively.",[534,869,871],{"id":870},"rendering-parity-is-part-of-the-agent-contract","Rendering parity is part of the agent contract",[526,873,874,875,878],{},"A chat agent that emits a correct ",[557,876,877],{},"ac_suggested_actions"," JSON block but renders a blank chip row is broken from the user's point of view — even though every behaviour eval passes. The agent's contract is \"what the user sees,\" not \"what bytes the agent produces.\"",[526,880,881],{},"Two consequences for how to test:",[631,883,884,894],{},[567,885,886,889,890,893],{},[542,887,888],{},"The renderer is in scope."," Treat the frontend that consumes ",[557,891,892],{},"ac_*"," blocks as part of the agent boundary. A frontend regression that swallows a content block is an agent bug.",[567,895,896,899,900,903,904,907,908,911],{},[542,897,898],{},"One layer of evals isn't enough."," Stub-toolkit behaviour evals catch decision and prose regressions. They cannot catch a renderer that throws away ",[557,901,902],{},"actions"," because the schema expects ",[557,905,906],{},"options",". The cheapest remedy is a live-browser eval loop (see ",[530,909,910],{"href":76},"System prompt architecture › What to test",") on the small set of cases where rendering parity matters — every content-block change, every per-turn-preamble change, every page-context payload change.",[526,913,914],{},"Knowing where the boundary sits also tells you where to fix gaps. A missing body preview in an approval card is rarely an agent problem — the page-context payload didn't ship the body field. A blank chip row when the JSON looks fine is a renderer problem. The shape of the failure tells you which side of the boundary owns the fix.",[534,916,918],{"id":917},"key-takeaways","Key takeaways",[631,920,921,927,933,939,945],{},[567,922,923,926],{},[542,924,925],{},"Context engineering is where chat-agent quality lives."," Treat the prompt as a layered envelope, keep the cacheable prefix stable, and put per-turn dynamism in a preamble below the cache boundary.",[567,928,929,932],{},[542,930,931],{},"Single agent loop is the right default."," Multi-agent only when a concrete failure mode demands it.",[567,934,935,938],{},[542,936,937],{},"Memory is two stores."," Short-term lives in the window, long-term lives outside. The rolling summary is the bridge; persist it so you stop paying to re-derive it.",[567,940,941,944],{},[542,942,943],{},"Tool design is API design for the model."," One tool one verb, docstrings with when-to-use and when-not, return shapes the model can read as text.",[567,946,947,950],{},[542,948,949],{},"Rendering parity is in scope."," A correct JSON block that renders blank is broken. Reserve a live-browser eval loop for the cases where rendering parity matters.",{"title":559,"searchDepth":32,"depth":293,"links":952},[953,954,955,956,957,958,959,960,961,962],{"id":536,"depth":32,"text":537},{"id":599,"depth":32,"text":600},{"id":619,"depth":32,"text":620},{"id":665,"depth":32,"text":666},{"id":687,"depth":32,"text":688},{"id":759,"depth":32,"text":760},{"id":814,"depth":32,"text":815},{"id":850,"depth":32,"text":851},{"id":870,"depth":32,"text":871},{"id":917,"depth":32,"text":918},"md",{},true,[967,968],"agents\u002Fchat","agents\u002Fconcepts\u002Fsystem-prompt-architecture",{"title":69,"description":70},"agents\u002Fconcepts\u002Fchat-agent-design-principles",[12,14,24,73],"noDWCSy-9rPJVM2f43Q-X_w1M2bVf4-VEiu1kuzgaWk",1783345922928]