PATTERN Cited by 1 source
Flattened tool architecture¶
Intent¶
Collapse every product's capabilities from separate sub-agent tool surfaces into a single, uniformly named, directly-callable tool surface for the orchestrator LLM. Nothing is paraphrased through a second agent.
Mechanism¶
Every operation is exposed as a typed, namespaced action:
jira__search_issues, confluence__get_page,
google_calendar__list_events. The orchestrator's LLM calls these
directly and sees raw arguments, raw responses, and raw errors — not
a paraphrase from an intermediate agent.
When a call fails or returns something unexpected, the same LLM that made the call reads the failure and decides what to do next: retry with different arguments, fall back to a related tool, or surface the gap to the user.
Trade-offs¶
| Benefit | Cost |
|---|---|
| End-to-end visibility of tool results + errors | Large flat tool catalog risks selection degradation |
| Recovery is part of the reasoning loop | Mitigated by patterns/progressive-tool-disclosure-meta-tools |
| One model migration (not N sub-agents) | Requires careful namespace design |
| No per-product schema tax per invocation | Loses sub-agent prompt specialisation (mitigated by SKILL.md) |
Complementary patterns¶
- Progressive disclosure — avoids paying schema cost for the full flattened surface upfront.
- SKILL.md — replaces the per-product prompt expertise that previously lived inside sub-agent system prompts.
Seen in¶
- sources/2026-06-18-atlassian-long-horizon-reasoning-engine — Atlassian Long Horizon flattens Jira + Confluence + Bitbucket + JSM + Compass + third-party connectors into a single namespaced tool surface callable by one LLM.