Intelligence layers
Coro’s behaviour is authored as Markdown: agents, workflows, skills, and memory bundles. Shipping updates does not require recompiling the runner—rather, deterministic resolver code overlays several sources into the tree a job actually reads.
Three layers
| Layer | Typical location | Audience |
|---|---|---|
| Base | Package @coro-ai/intelligence-base inside the runner | Generic, tenant-agnostic defaults |
| Tenant overlay | Settings → Advanced → Paths → Intelligence git remote (solo), explicit tenant.overlay in config, or the cloud bundle (team) | Company-specific snippets, trackers, wording |
| Repo overlay | <repository>/.coro/ in the cloned project | Repo-local conventions |
At runtime these stack into <workingDir>/<jobId>/_intelligence/ so every phase sees a single unified tree.
Merge semantics
Two rules apply deterministically:
| Paths | Behaviour | Why |
|---|---|---|
.claude/CLAUDE.md | Append with provenance banners | Everyone extends the same bootstrap instructions |
memory/**/*.md | Append with banners | Knowledge accumulates; nothing is silently erased |
Everything else (agents/, workflows/, .claude/skills/, etc.) | Last-wins replacement per file path | Overrides are explicit and predictable |
Because replacement is per-file, a tenant can drop in a customised agents/coder.md without touching unrelated agents.
When the resolver runs
Resolution happens:
- At job start — Base + tenant are always known.
- At phase boundaries — The resolver re-materialises idempotently. That matters because many jobs clone the target repo in an early phase; only afterwards does
.coro/exist on disk, which is picked up automatically on the next boundary.
Agents must treat _intelligence as read-only product of the resolver. Writable proposal flows target explicit tenant or repo git clones—never the synthesized tree.
Go deeper
- Tenant overlay guide — How to publish and iterate on overlay repositories.
- Repo overlay guide — Check in per-project
.coro/customisations safely.