Shared Agents
Drawing on the agents that serve every Workflow, not just this one
About this workflow
Drawing on the agents that serve several Workflows rather than any one of them. These are the systems-of-record readers and cross-cutting analysts — usage and behavior, win/loss, capacity, stakeholders, prior decisions, the feedback corpus — that many Workflows depend on and none of them owns. The work runs from finding the shared agent that already supplies what you need, through confirming the access it runs on is authorized, to promoting a recurring need into the library rather than solving it privately for the fourth time.
Its purpose is to stop the same supplier being rebuilt inside every Workflow that needs it. The count of these is stable — it does not grow with the number of Workflows, because systems-of-record access and cross-cutting analysis are both finite — so a discipline with forty Workflows needs roughly the same shared library as one with five. Companion agents live here too: they run on another agent’s output rather than inside a Workflow, so they belong to none.
The recognizable task
- A Workflow needs data that lives in a system of record rather than in the task itself
- The same analysis has been rebuilt inside three or more Workflows
- A connector the library depends on is unauthorized and everything downstream of it is starved
- A second-pass discipline — a red team, a stress test, a reframe — is wanted on top of an agent’s output
- A recurring need is met once in the library, not rebuilt inside each Workflow that has it
- Every shared agent names the Workflows it feeds, so its blast radius is visible before it changes
- The access or connector each supplier depends on is named, and a blocked one is reported as a dependency rather than a footnote
- Companions state what they add that the agent they run on could not produce itself
- Nothing lands here by default — an agent belongs to the library because it serves several Workflows, not because nobody chose a home for it