# Why a Workflow
## Teams already have Agents
Engineering teams already work in Claude Code, Codex, Cursor or a managed Agent environment, and many run team Bots. A hosted knowledge platform would ask them to move their sources, permissions and review habits somewhere new. Context goes the other way: it adds skills to the Agents a team already uses, and a local CLI does the deterministic work. The same skills run in a local coding Agent or a managed Agent environment.
## Semantic work and deterministic work
Knowledge production mixes two kinds of work:
| Kind | Examples | Done by |
| --- | --- | --- |
| Semantic | Reading evidence, proposing structure, writing and explaining | The Agent |
| Deterministic | Recording source boundaries, capturing snapshots, indexing code, checking evidence, staging candidates, applying reviews, building | The CLI |
| Decisions | Goal, source permission, scope, structure, review, output | People |
The CLI never calls an LLM and never silently clones, fetches, installs or builds a source repository; registering a source does not grant permission to read its contents, and review decisions stay with people. That keeps the parts that must be repeatable out of the model's hands, while the Agent stays free to choose the best wording and structure.
## A workflow, not a long prompt
The lifecycle is long: sources must be scoped and captured, articles written against evidence, human Gates may pause the run, and approved knowledge must be closed, verified and built. Putting all of that in one prompt would be fragile and expensive. Instead the workflow is a contract: at each step the CLI returns only the action that is legal now, the resources to read for it and the commands to run. Interrupting and resuming converge from the actual state of the Context knowledge workspace rather than from conversation memory. See [Workflow Execution]().
## From one person's Agent to a knowledge service
Because the skills are platform-independent, a team can run them as a resident knowledge service: an Agent environment with the Context plugin, a Bot prompt and remote code reading, taking requests from chat, the web, schedules or an API. It produces, updates and answers continuously, and people step in only at the decisions that matter — the work-start report, the review report and scope trade-offs.
Shared knowledge that needs a lot of searching and confirmation, and answers that must be available at any time, suit such a resident service. Knowledge for a small module can simply live in the repository's `docs/`.
---
## Sources
- note:20261012/knowledge-service-agent.md · knowledge-service-agent.md L9–L11
- [context/packages/context-cli/README.md L22–L32 · 3b0ce0a]()
- [context/README.md L101–L104 · 3b0ce0a]()
- [context/packages/context-cli/README.md L28–L32 · 3b0ce0a]()
- [context/packages/context-cli/README.md L182–L184 · 3b0ce0a]()
- [context/docs/en/case-studies/agent-graph-workflow.md L5–L7 · 3b0ce0a]()
- [context/docs/en/case-studies/agent-graph-workflow.md L38–L42 · 3b0ce0a]()
- note:20261012/knowledge-service-agent.md · knowledge-service-agent.md L15–L24
- note:20261012/knowledge-service-agent.md · knowledge-service-agent.md L39–L41