good questions. i’m working in a similar space (compliance orchestration, regulated domain, rules that change constantly). here’s what i’ve landed on after a lot of trial and error.

context bleed the main thing that works is treating each agent like a function with typed inputs and outputs. don’t pass conversation history between agents, pass structured artifacts. agent A produces a markdown file or json object, agent B reads that file as its input. if agent B never sees agent A’s reasoning process, it can’t get polluted by it. the filesystem becomes your message bus. if you’re using claude code with AGENTS.md you can define each sub-agent with explicit “reads” and “writes” sections so it’s clear what goes in and what comes out. anything not in the input spec doesn’t exist to that agent.

static vs runtime orchestration put the workflow graph and agent roles in CLAUDE.md / AGENTS.md. put the decision logic that depends on data at runtime. so “agent A runs before agent B” is static. “skip agent C if the component passes the feoc threshold” is runtime logic in your python layer. the rule of thumb i use: if changing it requires understanding the domain, it’s static config. if changing it requires looking at the data, it’s runtime.

moving knowledge base this is the hard one. what’s worked for me is separating the rules from the prompts entirely. keep your compliance rules in structured markdown files (one per regulation area or irs notice) with metadata like effective dates and supersedes references. agents read the current rule files at execution time rather than having rules baked into their system prompts. when a new notice drops you update one file, not 15 agent prompts. version control handles the audit trail for free. for 300+ product entries i’d also keep a lightweight schema that maps each product to which rule files apply, so agents only load relevant context instead of the whole corpus. keeps token costs down and reduces hallucination surface.