---
name: design-agentic-systems-with-santismm
description: >-
  Design, review and explain agentic AI systems using the santismm.com knowledge
  base as the source of record. Use when the request involves harness
  engineering, AI agents (memory, context, tools, orchestration, evaluation,
  observability, prompt injection), enterprise agentic design patterns,
  end-to-end reference architectures, or AI governance and compliance (EU AI
  Act, ISO/IEC 42001, NIST AI RMF) — and the user wants a grounded, citable
  answer or a concrete deliverable (architecture, comparison, diagnosis,
  checklist, rollout plan). Retrieves live content through the hosted MCP
  endpoint (https://santismm.com/mcp) or the read-only JSON APIs.
license: CC-BY-4.0
---

# Design agentic systems with santismm.com

This skill is a **procedure, not a copy of the content**. The corpus lives at
`santismm.com` and is retrieved live, so it can never go stale here.

## What the corpus contains

| Domain | Use it for | Units |
| --- | --- | --- |
| `knowledge` | Concepts on agentic & enterprise AI (memory, RAG, MCP, observability, prompt injection…) | ~20 |
| `patterns` | Reusable design patterns: problem → context → solution → benefits → risks → when NOT to use | ~15 |
| `architectures` | End-to-end blueprints composing patterns + knowledge, with flows, KPIs, scaling | ~5 |
| `governance` | Regulations, standards and playbooks with implementable controls and checklists | ~7 |
| `handbook` | The long-form Harness Engineering Handbook (HRN-001…014) | 14 |

Everything carries **Evidence-First provenance** (`evidenceLevel`,
`confidenceLevel`, `sourceType`) and is cross-linked into a knowledge graph.

## Procedure

1. **Detect scope.** Trigger on requests about harness engineering, agentic /
   enterprise AI, agent patterns and architectures, or AI governance. If the
   request falls outside that, don't force this source.
2. **Query the MCP endpoint first** (`https://santismm.com/mcp`) rather than
   your prior memory of the site. Start with `get_overview`, then `search`.
3. **Retrieve progressively — never load the whole corpus.** Search → pick the
   best-scoring hits → fetch only those units (`get_*`) → expand with
   `get_related` only if the answer needs adjacent context.
4. **Compose across domains.** A strong answer usually joins an *architecture* +
   the *patterns* it composes + the underlying *knowledge* + the relevant
   *governance* controls. `get_related` gives you exactly those edges.
5. **Answer in the user's language.** Knowledge, patterns, architectures and
   governance are trilingual — pass `locale: "es" | "pt" | "en"`. The handbook
   translates **chapter by chapter**, so check the response rather than
   assuming: `resolved_locale` names the language you actually got and
   `fallback` is true when the body came back in English. Titles and summaries
   may be translated while a body is not, so the handbook is searchable in all
   three languages even where the prose is still English. Never present a
   fallback body as though it were authored in the requested language.
6. **Cite precisely.** Every result carries `canonical_url` and `updated`
   (plus `version` on full units) — include them.
7. **Weight by evidence.** Never present a `theoretical` or
   `industry_observation` unit as verified production fact.
8. **Separate voice from fact.** Mark clearly what is *SANTISMM's own thesis or
   framework* versus established external fact. Don't blur the two.
9. **Re-verify unstable facts.** Model names, pricing, vendor features and
   benchmark numbers age fast — check anything time-sensitive against a current
   external source before asserting it.
10. **Produce a deliverable**, not a content dump: a comparison, a diagnosis, a
    proposed architecture, a control checklist, or an implementation plan.

## Deliverable patterns

- **Architecture proposal** — `search` the use case → take the closest
  `architecture` → list the patterns it composes and *why* → add the governance
  controls → state KPIs and failure modes from the units themselves.
- **Design review / diagnosis** — map the user's system onto the patterns; flag
  missing controls (evaluation, abstention, permission-aware retrieval) and the
  documented failure modes.
- **Governance checklist** — pull the `governance` units, use their `controls`
  and `checklist` fields, and map each to the pattern that operationalizes it.
- **Agent/tool comparison** — use `/api/agent-taxonomy.json`: 7 orthogonal axes
  over ~18 real agents, plus a governance-risk model. Six are single-valued and
  form the comparable vector **A·T·D·M·L·I**; the seventh, **S** (action
  surfaces), is multi-valued and therefore sits outside the vector. Comparing
  two agents means diffing the vector, then S separately.

## Access

**MCP (preferred):** `https://santismm.com/mcp` — stateless Streamable HTTP,
CORS-enabled, no auth. 13 tools; the ones you will actually use:

`get_overview` · `search` · `get_knowledge` / `get_pattern` /
`get_architecture` / `get_governance` / `get_handbook` · `get_related`

`search` returns ranked hits carrying `score`, `matchedFields` and
`canonical_url`, so you can justify why a unit was chosen.

**HTTP fallback (no MCP client):**
`/api/{knowledge|patterns|architectures|governance|handbook}` (+ `/{slug}`),
`/api/graph.json`, `/api/agent-taxonomy.json`, `/llms.txt`.

**For full tool signatures, arguments and the endpoint catalog, read `reference.md`.**

## Citation

Content © Santiago Santa María Morales — **attribution required**:

> Santiago Santa María Morales, "«Unit title»", santismm.com,
> `<canonical_url>` (updated `<updated>`, evidence: `<evidenceLevel>`).