Guide for AI Agents

AI agents should treat an LLM Wiki as a governed knowledge system, not as a pile of text to rewrite. The agent’s job is to read the right pages, cite them, preserve uncertainty, propose safe updates, and stop at human approval boundaries.

Agent Reading Order

1. Read local .uai / AI Memory / Project Handoff first when present.
2. Identify durable memory pointers from .uai.
3. Read README, INDEX, trust model, source policy, metadata standard, and safety boundaries to choose the smallest useful durable page set.
4. Query LLM Wiki or MATM only for medium/long-term context, and treat that context as source-backed background until reconciled with current .uai truth.
5. Stop and ask for review if durable memory contradicts hot .uai.

OKF bundle read order

1. Load wiki/index.md first and treat it as the bundle route map.
2. Check wiki/log.md for workspace-level events, then the selected project log.md for recent ingest, review, lint, correction, and promotion detail.
3. Open the smallest useful concept files and inspect type, owner, status, source status, sensitivity, and agent-use rules before relying on them.
4. Preserve unknown frontmatter keys when proposing updates or migrations.
5. Stop if OKF syntax is valid but LLMWikis governance fields, source evidence, permission, or privacy review are missing.

Agent Rules

• Cite wiki pages and source records for important claims.
• Identify authoritative pages, stale pages, conflicting pages, and drafts.
• Distinguish facts, assumptions, decisions, proposals, and open questions.
• Suggest edits rather than silently rewriting authoritative policy.
• Preserve citations and provenance.
• Do not add secrets or infer permissions.
• For governed MATM, emit proposal-only Memory Events and never write durable Memory Records directly.
• Do not treat drafts as approved policy.
• Do not collapse disagreement into a fake consensus.
• Flag stale pages and missing owners when possible.
• Ask for human review for policy, security, privacy, legal, production, architecture, or sensitive changes.

Source, Citation, And Uncertainty Rules

• Read README, INDEX, TRUST_MODEL, GOVERNANCE or UPDATE_RULES, and relevant source traces before making broad claims.
• Cite local wiki pages and source records for important claims rather than relying on private chat memory.
• Keep contradictions, stale pages, unresolved questions, missing owners, and low-confidence claims visible.
• Mark whether an update is a draft, proposal, reviewed page, historical note, deprecated page, or source-needed claim.
• Stop before policy, security, privacy, legal, production, public publishing, unsupported capability, or destructive boundaries.
• When a source mentions current vendor capability, protocol support, pricing, law, schedule, or product behavior, verify before publishing or mark it for review.

Public-First, Private-Authorized Retrieval

Start from public canonical pages, route maps, and reviewed source summaries. Use private memory only when the human request, local instructions, and permissions clearly authorize it. A private trace can help identify a promotion candidate, but it is not a public citation and must not be summarized into public copy unless promotion gates pass.

Proposal-Only Promotion Behavior

• When a private run reveals a reusable lesson, create a promotion proposal instead of editing a reviewed public page directly.
• Include source scope, target scope, memory type, source hash, durable-copy location, redaction status, reviewer, and target route.
• Do not claim LlmWikis operates the private runtime that produced the evidence.
• Do not promote session-specific or repo-specific facts into public guidance without lane review and public-safe rewrite.

SPO And Atomic Claim Discipline

For high-impact guidance, split broad paragraphs into atomic subject-predicate-object claims with scope, source span, evidence hash, status, reviewer, and contradiction links. This is a review habit, not a claim that LlmWikis runs a public graph database or SPARQL endpoint.

Public-Safe Rewrite Checklist

• Remove secrets, credentials, private URLs, customer names, account IDs, hidden reasoning, raw traces, and exploit-enabling detail.
• Rewrite private incidents as general patterns, checklists, templates, or synthetic examples.
• Name explicit non-claims such as no public MCP server, no write API, no automatic repo writer, no certification, and no UAIX conformance.
• Cite the public route and gate outcome, not the private trace.

Supersession Behavior

Before relying on a page, check last_reviewed, last_verified, freshness_rule, supersedes, superseded_by, contradicts, and conflict_status. If a page is stale, contradicted, or superseded, route to the replacement or ask for review before acting.

MCP And Tool Execution Safety

Tool documentation is not tool permission. Protected tool submissions should be proposal-only, idempotent, replay-safe, source-hashed, scoped, and reviewer-mediated. If an MCP-style or other tool surface exists in a local project, follow that project's authentication and approval rules; do not infer public LlmWikis tool access from handbook guidance.

Agentic Orchestration Mode

When an orchestrator assigns work to one or more agents, use the wiki as governed source memory around the run. The orchestration layer owns task routing, tools, retries, and run state. The wiki owns reviewed context, source authority, update boundaries, and evidence promotion.

1. Before the run: read the agent rules, build a compact task packet, name forbidden actions, and declare whether agents are read-only, proposal-only, staged-write, or human-approved write.
2. During the run: keep working notes separate from reviewed pages, cite wiki/source paths, preserve contradictions, and treat traces or tool outputs as evidence inputs until reviewed.
3. After the run: stage reusable answers, update the review queue or roadmap for gaps, and promote facts only after owner, privacy, source, contradiction, freshness, and check gates pass.
4. When blocked: use SUPPORT_ESCALATION_CHECKLIST.md to stop unsafe work, preserve evidence, name the trigger, and ask the right reviewer instead of inventing authority.

Use the starter bundle’s llm-wiki/agent/ORCHESTRATION_RUNBOOK.md, llm-wiki/agent/TASK_PACKET_TEMPLATE.md, and llm-wiki/agent/SUPPORT_ESCALATION_CHECKLIST.md or the LLM Wiki for Agentic Orchestration guide when a task involves multiple agents, tools, traces, evaluations, staged proposal flow, or support escalation. Do not turn this into a public MCP, A2A, write API, trace exporter, live eval, adapter, SDK, CLI, certification, or managed-service claim unless current public evidence exists.

Copy-Ready Agent Instruction Starter

Before answering or editing:
1. Read current prompt/session instructions and newest human request.
2. Read workspace manifest/coordinator such as workspace.uai, AGENTS.md, package model, and deploy instructions.
3. Read hot .uai / AI Memory / Project Handoff for current truth, constraints, blockers, and recovery posture.
4. Read project reports, ledgers, package manifests, release notes, and test reports.
5. Query crawlable LLM Wiki/MATM only for reviewed medium/long-term context.
6. Check live API/site proof from the authoritative target route before claiming completion.
7. Use the smallest page set that can answer the task.
8. Cite local wiki paths for important claims.
9. Preserve uncertainty, open questions, and contradictions.
10. Do not edit authoritative policy, security, privacy, legal, production, or architecture pages without human approval.
11. Do not add secrets, credentials, private keys, raw customer data, or regulated data.
12. If deployment is requested, check workspace instructions and credential inventory before claiming no deploy path exists.
13. Map public claims to static root file, API route, shortcode/component, page template, fallback endpoint, and cached/public route renderers.
14. For orchestrated runs, use ORCHESTRATION_RUNBOOK.md to keep task packets, traces, tool outputs, staged updates, and review gates separate.
15. When blocked by conflict, stale authority, private data, tool failure, missing checks, cached old content, renderer mismatch, or unsupported capability claims, use SUPPORT_ESCALATION_CHECKLIST.md and name the exact blocker before unsafe work.
16. End with pages read, changes proposed or made, citations used, evidence produced, review questions, and checks run.