The operating model underneath practical AI work: memory, contracts, tools, scripts, checks, logs, and adoption loops.
AI capability as a system
What it is
AI capability is not access to a model. It is the system around the model: memory, source-of-truth discipline, task contracts, tools, scripts, verification, logs, secret handling, adoption rituals, and handover.
The model can be the most visible layer and still not be the durable part of the workflow. The durable part is the system that lets a team ask for work, bound it, run it, inspect it, improve it, and operate it again.
Learning goal
Learn to see AI work as capability design instead of prompt design. A good learning artifact should show the layers and explain which layer carries the risk: model quality, context quality, tool authority, data sensitivity, verification, adoption, or ownership.
Why it matters in production
Organizations often buy AI access faster than they build AI capability. That creates scattered usage: private prompts, untracked context, unclear data boundaries, no evaluation dataset, no fallback, and no owner when the first version breaks.
A system view makes the work inspectable. It lets a team ask: where is the source of truth, what authority does the agent have, how do we know the answer is good, and who owns the workflow after the demo?
How I actually build it
I use FOS as a lab where the layers are explicit:
- Graph and files hold durable context.
- Tickets hold task contracts and acceptance criteria.
- Skills guide judgment-heavy workflows.
- Scripts perform deterministic retrieval, sync, deploy, and validation.
- Model routing keeps provider choice separate from task intent.
- OpenBao-backed wrappers keep secrets out of prompts and repo-local content.
- Build logs, verification commands, and ticket notes create the audit trail.
The public cookbook extracts the transferable patterns while the private FOS implementation remains the working evidence.
Practice loop
- Pick one AI workflow and draw its layers.
- Mark which layers are currently implicit or missing.
- Identify one failure mode per layer.
- Build the smallest artifact that makes one missing layer inspectable.
- Record the learning as a ticket note, page, skill, script, or runbook.
Proof artifact
A useful proof is a capability map for one workflow. It should name the source of truth, task contract, model route, tools, authority boundary, verification, logs, owner, and handover path.
Current status
This page is the top-level map. The concrete proofs live on the more specific capability pages: guardrails, evaluation, red-teaming, orchestration, secrets, citizen-facing architecture, and handover.
What worked, what didn't
What worked is making the surrounding system visible. Once the layers are named, it becomes easier to decide whether a problem needs a better model, better context, a tool wrapper, a stricter permission boundary, or a human approval step.
What did not work is treating every AI failure as a prompt failure. Many failures are actually source, ownership, verification, or operating-model failures.
Next build
Create a public-safe capability map for one real FOS workflow and link each layer to a ticket, script, page, or verification command.