Capabilities & operations
Configuration.
For: developers and operators
Cardinal keeps the engagement-agnostic machinery and the customer-specific values strictly separate. A layered configuration lets one set of skills and role briefs serve any engagement: the base stays pure, and a per-engagement pack supplies the specifics.
The configuration layers
Configuration is layered so that nothing customer-specific ever leaks into the shared machinery. A purity check at bootstrap enforces exactly that separation.
| Layer | What it holds |
|---|---|
| Workflow | Which roles exist, the model each runs, and which to spawn at startup. |
| Engagement pack | The customer-specific values — names, identifiers, channels — that layer over the base. |
| Engagement-agnostic base | The skills and role briefs, written once and reused; deliberately free of any customer detail. |
| Role overlays | Per-role, per-engagement specifics that bind to a role brief at spawn time. |
Tool servers
The agents reach external systems — the database, the work-item tracker, and others — through tool servers declared in a registry. Each entry names what the server is, how it is reached, and how it authenticates. Engagement-specific coordinates are supplied by the pack, not hard-coded into a skill.
App settings
Engagement-level settings surfaced in the app — display preferences and the like — are read from the engagement configuration, so the app reflects the same source of truth the agents use rather than a separate store.
The skills this configures → · How it's validated at startup →