Portable agent pattern kits - clone the repo, bind a model, keep the boundary

A public pattern repo should work on someone else’s desk.

Not after a sales call. Not after a hidden credential exchange. Not after a private walkthrough. A reader should be able to clone the repo, bind a model, read the local graph and MCP surface, and get a bounded system running.

The StoneyTECH Trinity family now needs to meet one standard:

• StoneyTECH-Trinity-Learning-Agent
• StoneyTECH-Trinity-Evidence-Agent
• StoneyTECH-Trinity-GVAR-Engine

The point is not “support every provider on day one.” The point is portability of shape. The repo should teach the job, the boundary, and the upgrade path clearly enough for any competent builder to swap in a local agent, a vendor key, or an OpenRouter route without losing the pattern.

The real contract

“Bring a model and keep the pattern” sounds softer than it is.

It does not mean “good luck, wire up anything.” It means the repo ships enough structure for a different model path to step into place without changing the job definition.

Four things make the contract real:

1. a runnable local example
2. a bounded local MCP surface
3. a file-backed graph naming the important relationships
4. templates showing what stays stable when the provider changes

Without those four, a repo is mostly an opinion with setup instructions.

Why the repo should not start with a database story

The first public version should stay small.

File graphs come first because they are:

• inspectable in git
• portable across machines
• easy for an agent to read
• cheap to diff
• honest about what the pattern currently knows

The Trinity repos ship graph/nodes.json, graph/edges.json, and a small graph/README.md before any heavier datastore. The growth path can point toward Postgres, Neo4j, or a hosted graph later. The first responsibility is to make the boundary legible now.

This is the same rule the site keeps teaching: push work downward toward a more inspectable layer before autonomy expands.

Why the local MCP matters

The repo-local MCP is not there for spectacle.

Its job is to let an outside agent ask:

• what pattern this repo demonstrates
• which axioms it addresses
• what scenarios it supports
• what pairings it allows
• what the local graph says

This is a cleaner first contact than “read this whole README and infer the architecture.”

The StoneyTECH public content MCP still matters. It carries the shared doctrine for the site, the axioms, the published essays, and the ladder framing. The local repo MCP carries the repo truth. One gives family context. One gives repo context.

The split stays healthy.

Why the model should stay swappable

The public promise should never be “this only works with the provider used during authorship.”

The better promise is:

• bring a local agent
• or bring direct vendor keys
• or bring OpenRouter
• keep the job role names stable
• bind the provider at the edge

The Trinity repos now point toward:

• agents/graph-map.json
• providers/provider-map.example.json
• shadow/tribunal-config.example.json
• integrations/n8n/workflow-stub.jsonc

The job comes first. The role binding comes second. The provider comes third.

The order matters. It keeps the public lesson portable.

The three jobs still stay distinct

Portability does not mean sameness.

StoneyTECH-Trinity-Learning-Agent should still feel like the smallest loop in the set. One concept. One lesson or one recall action. One ledger update.

StoneyTECH-Trinity-Evidence-Agent should still feel like a bounded research surface. One subject. One brief. One inspectable claim boundary.

StoneyTECH-Trinity-GVAR-Engine should still feel like explicit workflow. Verifier lanes, adjudication, refinement, and stop conditions.

Same portability rule. Different job shapes.

Why the upgrade clues belong in public

A public repo becomes more useful when it tells the truth about how it grows up.

Visible seams should exist for:

• n8n orchestration
• shadow tribunals
• provider routing
• stronger graph storage
• hosted MCP transport

The upgrade seam is part of the teaching value.

A reader should be able to say:

This works now. This is where local files stop being enough. This is where a workflow canvas, bigger graph store, or hosted MCP can take over.

This is much more generous than pretending the starter version is already the final architecture.

The standard from here

If an article points to one of these repos, a cold reader should be able to:

1. clone it
2. bring a model path
3. run the local example
4. query the local MCP
5. inspect the file graph
6. understand how to pair it with the other Trinity repos
7. see where to upgrade it without guessing

The list is enough.

Not a platform. Not a private runtime. Not a hidden dependency maze. A working public pattern with honest seams.

This makes a repo worth citing in public.