A formal specification for how agents receive instructions, match patterns, create new patterns, propagate policies, and communicate. This extends the current HAAK agent architecture (fixed roles, manually scaffolded) toward a self-modifying system where agents learn and share behavioral patterns.
#Relationship to existing architecture
The current HAAK system uses manually authored patterns (skills, processes, policies). This spec describes how agents could create, search for, and evaluate patterns autonomously — the "learning etc" phase from the [[Assessment of Priorities]] roadmap.
Mapping to current types:
- Pattern = generalized name for process / policy / protocol / skill
- Constitution = root policy (already implemented in process-architecture)
- Policy = cross-cutting constraint (already implemented)
- Instructor/instructee = new role model extending current fixed agent types
#A. Pattern matching and execution
An agent receives an instruction (prompt):
- Check if any existing pattern matches the instruction
- Match could be specified in many ways
- Analogous to Claude/OpenAI skill matching
- If match found → use the pattern to complete the instruction
- If no match → ask for feedback:
a. Stop the task (someone else does it) b. Request clarification → check again (1) c. Create a new pattern (B)
#B. Pattern creation and search
When an agent needs a new pattern:
- Search for analogues:
a. Own library of previously used patterns b. Other agents' pattern libraries (see C) c. External patterns (web search) d. Homology / metaphor from other domains e. Instructor's guidelines/policy (B.1.f)
- Reason about the needed pattern based on policy + analogy
- Propose a new pattern to complete the task
#B.1.f: Instructor policy propagation
The instructor (requesting agent) passes guidelines that:
- Are implicit in the instruction
- Are rules/guidelines of the most general sort
- Apply to every new pattern the instructee creates
- Need not be repeated every instruction if the agent remembers instructor policy
- Can be passed like a system prompt (limits to per-use scope otherwise)
Terminology:
- Instructor = agent making the request
- Instructee = agent creating/learning the new pattern
#C. Policy passing between agents
An agent requesting help passes its policies to the receiving agent (like a system prompt — rules, not specific instructions).
An agent may refuse or request clarification if:
- It checks patterns and finds no match (→ A.3)
- Requester may then: try another agent type, change the request, clarify, or escalate
Role dynamics: An agent may act as requester, instructor, executor, or instructee at different times. These are roles, not types — unless precluded by policy.
#D. Policy framework
#D.1–D.4: Policy hierarchy
- Constitution: rules followed by all agents (requires human approval to change)
- Agent-specific policies: rules specific to an agent's capabilities; any pattern created/used must adhere
- Policies may be shared across agents; they define/limit domains of action
- During cooperation: policies of both requester AND executor must be followed
#D.5: Policy creation and amendment
a. Constitution changes require user/human approval b. Agent-created policies should be human-checked c. A policy is generally a generalization of a successful pattern or set of patterns d. Proposed policies must be checked for:
- Adherence to constitution
- Non-collision with other policies
- Non-contradiction
e. Policies should be atomic (~1 sentence + explanation) for composability f. Automatic periodic policy review for non-contradiction, especially with constitution
#D.6: Communication between agents
a. Communication by request or self-initiation (if policy/instruction allows) b. All communication recorded — external, in both agents' output, auditable c. Communication may be on-the-record (in agent memory/patterns) or off-the-record (current session only; transcripts not part of agent memory by default) d. Group communication (>2 agents): entire transcript saved to each e. Limit communication to preserve:
- Independent views
- Prevent leakage / conformity
- Support adversarial processes
f. Agents may review other agents' performance based on task output (part of pattern evaluation)
#Connection to inscription project
The Library Theorem (inscription) formalizes why external memory (patterns, policies) enables capabilities beyond in-context reasoning. This spec is the operational counterpart: how agents actually use the external library. A learning-based inscription agent would implement sections A-B (pattern matching + creation) with the formal guarantees the theorem provides.
#Open questions
- Is a shared Turing tape/machine with multiple read/write heads equivalent to or super-Turing? [Lit search needed]
- How does pattern evaluation work? (Referenced as B.5 but not yet specified)
- When does a pattern graduate to a policy? (Relates to process-architecture maturity model)
- How is "match" specified? (Embedding similarity? Keyword? Structural?)
haak · created 2026-02-22 · source: handwritten notes Feb 17-19 2026 · zach
Architecture 05 — Inscription Architecture — 2026 — Zachary F. Mainen / HAAK