coaiajs 0.1.0

package/articles/academic/model-context-protocol-interagent.md

@@ -0,0 +1,161 @@
+# Model Context Protocol as Standardized Interagent Communication
+
+> Academic brief for the CoAiA.js project — MCP as the universal protocol for tool-using AI agents, examining Anthropic's design, transport mechanisms, and the tool/resource/prompt primitive model.
+
+## Abstract
+
+The Model Context Protocol (MCP), introduced by Anthropic in late 2024, establishes an open standard for connecting AI language models to external tools, data sources, and services. Often described as "USB-C for AI integration," MCP addresses the N×M integration problem that has plagued agent-tool ecosystems by defining a single, well-typed protocol through which any compliant AI host can communicate with any compliant tool server. This paper analyzes MCP's architectural design—its JSON-RPC 2.0 foundation, dual-transport model (stdio for local, HTTP for distributed), and three-primitive abstraction (tools, resources, prompts). We examine how MCP enables dynamic tool discovery, maintains session state, and enforces human-in-the-loop safety boundaries. The analysis situates MCP within the broader landscape of agent communication protocols and evaluates its implications for building composable, observable, and secure AI agent systems within CoAiA.js.
+
+## Introduction
+
+The proliferation of AI agents that interact with external tools—databases, APIs, file systems, code execution environments—has created a fragmentation crisis. Each tool integration requires custom adapter code: prompt formatting, response parsing, error handling, and authentication logic unique to that specific tool-host pairing. For an ecosystem with N AI hosts and M tools, this produces N×M integration points, each independently maintained and tested [1].
+
+The Language Server Protocol (LSP), developed by Microsoft for IDE integration, demonstrated that a well-designed protocol can collapse this N×M problem to N+M: each host implements the protocol once, each tool implements it once, and all combinations work. MCP applies this same principle to AI agent-tool communication [2].
+
+Anthropic released MCP as an open specification in November 2024, accompanied by reference implementations in TypeScript and Python, and a growing ecosystem of community-built MCP servers for systems including GitHub, PostgreSQL, Slack, Puppeteer, and file systems [3].
+
+## Background
+
+### The Agent-Tool Integration Problem
+
+Modern AI agents require access to diverse external capabilities:
+- **Data retrieval:** Querying databases, searching documents, reading files
+- **Action execution:** Creating records, sending messages, deploying code
+- **Context provision:** Fetching project structure, reading configuration, accessing knowledge bases
+- **Observation:** Monitoring system state, checking test results, reading logs
+
+Without a standard protocol, each capability requires bespoke integration logic within each agent framework—LangChain, CrewAI, AutoGen, and custom implementations each maintain their own tool interfaces, parsing logic, and error handling.
+
+### Prior Art: Language Server Protocol
+
+LSP, standardized by Microsoft in 2016, provides a direct architectural precedent for MCP. LSP defines:
+- A JSON-RPC 2.0 message protocol
+- Capability negotiation between client and server
+- A standard set of operations (completions, diagnostics, hover info)
+- Transport over stdio or TCP
+
+MCP follows this design closely, adapting it from IDE-language tool communication to AI agent-tool communication [4].
+
+## Analysis
+
+### Protocol Architecture
+
+MCP defines three roles in a clear hierarchy:
+
+1. **Host:** The overarching application (IDE, chat interface, agent runtime) that manages one or more MCP clients.
+2. **Client:** A protocol handler that maintains a 1:1 session with a single MCP server. The client translates between the host's intent and the server's capabilities.
+3. **Server:** A process that exposes tools, resources, and prompts to the client, handling actual execution and data access.
+
+This separation enables clean architectural boundaries: the host manages user interaction and policy decisions, the client handles protocol mechanics, and the server encapsulates tool-specific logic.
+
+### Message Protocol: JSON-RPC 2.0
+
+All MCP communication uses JSON-RPC 2.0, a lightweight remote procedure call protocol that defines:
+
+```json
+// Request
+{"jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": {"name": "read_file", "arguments": {"path": "/src/index.ts"}}}
+
+// Response
+{"jsonrpc": "2.0", "id": 1, "result": {"content": [{"type": "text", "text": "import { Server } from '@modelcontextprotocol/sdk';"}]}}
+
+// Notification (no response expected)
+{"jsonrpc": "2.0", "method": "notifications/progress", "params": {"progressToken": "abc", "progress": 50, "total": 100}}
+```
+
+The choice of JSON-RPC over alternatives (Protocol Buffers, MessagePack) prioritizes debuggability and ecosystem accessibility over raw performance—a deliberate trade-off for a protocol intended to be adopted broadly across diverse language ecosystems [5].
+
+### Transport Mechanisms
+
+MCP supports two transport modes, each optimized for different deployment contexts:
+
+**Stdio Transport:** For local, same-machine integration. The MCP server runs as a child process of the client, communicating through standard input/output streams. This mode:
+- Requires zero network configuration
+- Provides natural process lifecycle management (client starts/stops the server)
+- Offers inherent security through process isolation
+- Is ideal for development environments, desktop applications, and single-machine agent runtimes
+
+**HTTP Transport (Streamable HTTP):** For distributed deployments where the MCP server runs on a different machine or as a shared service. This mode:
+- Supports Server-Sent Events (SSE) for real-time server-to-client notifications
+- Requires authentication and authorization mechanisms
+- Enables shared tool servers serving multiple clients
+- Is suited for production, cloud, and multi-agent deployments [6]
+
+### The Three Primitives
+
+MCP's abstraction model centers on three primitive types that encompass the full range of agent-tool interactions:
+
+**Tools:** Executable functions that the AI agent can invoke. Tools are the most dynamic primitive—they represent actions with side effects.
+
+```json
+{
+  "name": "create_issue",
+  "description": "Create a new GitHub issue",
+  "inputSchema": {
+    "type": "object",
+    "properties": {
+      "title": {"type": "string"},
+      "body": {"type": "string"},
+      "labels": {"type": "array", "items": {"type": "string"}}
+    },
+    "required": ["title"]
+  }
+}
+```
+
+**Resources:** Data sources that provide context to the model. Resources are read-oriented and can be static (file contents) or dynamic (database query results).
+
+**Prompts:** Instruction templates that guide the model's behavior. Prompts enable servers to provide domain-specific guidance that shapes how the model uses the server's tools and resources.
+
+### Dynamic Tool Discovery
+
+A critical innovation in MCP is runtime tool discovery. Rather than requiring static configuration of available tools, clients can query servers for their capabilities at session initialization:
+
+```json
+// Client requests available tools
+{"jsonrpc": "2.0", "id": 1, "method": "tools/list"}
+
+// Server responds with tool schemas
+{"jsonrpc": "2.0", "id": 1, "result": {"tools": [
+  {"name": "read_file", "description": "Read a file's contents", "inputSchema": {...}},
+  {"name": "search_code", "description": "Search for patterns in code", "inputSchema": {...}}
+]}}
+```
+
+This dynamic discovery enables:
+- **Modular tool composition:** Agents connect to different MCP servers based on the task, discovering capabilities at runtime.
+- **Graceful degradation:** If a server is unavailable, the agent operates with reduced capabilities rather than failing entirely.
+- **Semantic tool selection:** LLMs can choose tools based on their descriptions, eliminating the need for hard-coded tool routing logic.
+
+### Human-in-the-Loop Safety
+
+MCP explicitly incorporates human approval gates for sensitive operations. The specification defines that tool invocations may require user consent, with the host application presenting confirmation dialogs for operations that modify state, access sensitive data, or perform irreversible actions [7].
+
+This design philosophy—making the human a mandatory checkpoint for high-impact operations—aligns with the creative orientation principle that agents should advance toward desired outcomes under human guidance, rather than operating autonomously on problem-solving heuristics.
+
+## Implications for CoAiA.js
+
+MCP serves as the standard communication layer in CoAiA.js for all external tool interactions:
+
+1. **Structural tension charts as MCP resources.** Active STCs are exposed as MCP resources, enabling any MCP-compliant host to read agent state.
+2. **MMOT evaluations as MCP tools.** The Managerial Moment of Truth cycle is exposed as an invocable tool, enabling external orchestrators to trigger self-evaluation.
+3. **JSONL memory as MCP resource.** Agent memory files are exposed through MCP's resource primitive, supporting both direct access and subscription to updates.
+4. **Multi-server composition.** A CoAiA.js agent can connect to multiple MCP servers simultaneously—one for code operations, one for observability (Langfuse), one for knowledge graph queries—composing capabilities dynamically.
+5. **Observability through protocol traces.** MCP's JSON-RPC format produces naturally structured logs that feed into the observability pipeline.
+
+## Conclusion
+
+The Model Context Protocol represents a maturation point for the AI agent ecosystem—the transition from bespoke, framework-specific tool integrations to a universal, well-typed protocol that enables composable agent architectures. By standardizing the three fundamental primitives of agent-tool interaction (tools, resources, prompts) over a debuggable JSON-RPC protocol with dual-transport support, MCP establishes the infrastructure layer that makes complex, multi-tool agent systems viable for production deployment.
+
+## References
+
+1. Anthropic. (2024). "Introducing the Model Context Protocol." https://www.anthropic.com/news/model-context-protocol
+2. Model Context Protocol Specification. (2025). https://modelcontextprotocol.io/specification/2025-03-26
+3. Model Context Protocol GitHub. https://github.com/modelcontextprotocol/modelcontextprotocol
+4. InfoQ. (2024). "Anthropic Publishes Model Context Protocol Specification." https://www.infoq.com/news/2024/12/anthropic-model-context-protocol/
+5. LogRocket. (2024). "Understanding Anthropic's Model Context Protocol." https://blog.logrocket.com/understanding-anthropic-model-context-protocol-mcp/
+6. BridgeApp AI. (2024). "A Complete Guide to MCP: Architecture, Integration, and Best Practices." https://bridgeapp.ai/resources/blog/a-complete-guide-to-model-context-protocol-mcp-architecture-integration-and-best-practices
+7. Model Context Protocol Info. "MCP Docs." https://modelcontextprotocol.info/docs/
+8. Wikipedia. (2025). "Model Context Protocol." https://en.wikipedia.org/wiki/Model_Context_Protocol
+9. UPP Technology. (2024). "Anthropic's MCP: The USB-C Standard for AI Integration." https://www.upp-technology.com/en/news/anthropics-model-context-protocol-mcp-the-usb-c-standard-for-ai-integration/
+10. Weights & Biases. (2024). "The Model Context Protocol by Anthropic: Origins, Functionality, and Impact." https://wandb.ai/onlineinference/mcp/reports/The-Model-Context-Protocol-MCP-by-Anthropic

package/articles/academic/pde-prompt-decomposition.md

@@ -0,0 +1,186 @@
+# Prompt Decomposition as Engineering Methodology
+
+> Academic brief for the CoAiA.js project — Breaking complex prompts into primary/secondary intents, context requirements, and Four Directions action stacks through systematic decomposition.
+
+## Abstract
+
+Complex prompts submitted to large language models frequently contain multiple intents—some explicit, some implied by hedging language or contextual assumptions. When processed holistically, LLMs tend to prioritize salient explicit intents while dropping implicit ones, resulting in incomplete task execution. This paper presents Prompt Decomposition Engineering (PDE) as a systematic methodology for analyzing complex prompts before execution. PDE identifies primary and secondary intents, extracts implicit requirements from hedging language ("maybe," "also consider," "if possible"), maps dependencies between action items, and organizes them into executable Four Directions action stacks. We compare PDE with existing reasoning strategies—Chain-of-Thought (CoT), Tree-of-Thought (ToT), Self-Consistency, and Decomposed Prompting (DecomP)—and argue that PDE operates at a fundamentally different level: it decomposes the *input prompt* rather than the *reasoning process*, serving as a completeness safeguard rather than a reasoning enhancer. The methodology is evaluated in the context of the CoAiA.js PDE engine.
+
+## Introduction
+
+A user submits the following prompt to an AI agent:
+
+> "Set up the project with TypeScript, add ESLint and Prettier, maybe also configure Husky for pre-commit hooks, and write a basic README. Oh and we'll probably need tests too—Jest should work. Make sure the CI/CD pipeline runs everything."
+
+This 44-word prompt contains at least seven distinct action items, three implicit dependencies, two hedged requests ("maybe," "probably"), and one underdetermined requirement ("runs everything"). A capable LLM might execute the most salient items (TypeScript setup, ESLint, README) while dropping the hedged ones (Husky, Jest) and underdetermining others (CI/CD scope) [1].
+
+The fundamental issue is not that LLMs lack capability—it's that complex prompts exceed the scope of single-pass intent extraction. Prompt Decomposition Engineering addresses this by introducing a systematic pre-processing phase that decomposes complex prompts into structured, complete, and dependency-mapped action specifications before execution begins.
+
+## Background
+
+### Existing Prompt Engineering Strategies
+
+The prompt engineering landscape has produced several strategies for improving LLM reasoning on complex tasks:
+
+**Chain-of-Thought (CoT):** Introduced by Wei et al. (2022), CoT prompts models to "think step by step," revealing intermediate reasoning. This improves accuracy on multi-step problems but does not prevent intent loss—the model may reason carefully about a subset of intents while still dropping others [2].
+
+**Tree-of-Thought (ToT):** Yao et al. (2023) extended CoT to explore multiple reasoning branches simultaneously, evaluating alternative solution paths. ToT improves exploration of solution spaces but addresses reasoning quality, not input completeness—it assumes all intents have been correctly identified [3].
+
+**Self-Consistency:** Wang et al. (2022) proposed sampling multiple reasoning paths and selecting the most consistent answer. This reduces errors in reasoning but does not address the prior problem of intent extraction from complex inputs [4].
+
+**Decomposed Prompting (DecomP):** Khot et al. (2022) introduced decomposition of complex questions into sub-questions, each handled by specialized sub-prompts. DecomP is the closest precursor to PDE but operates on reasoning decomposition rather than input prompt decomposition—it assumes the question is well-specified and decomposes the answer strategy [5].
+
+**Plan-and-Solve (PS):** Wang et al. (2023) proposed devising a plan before executing, then following the plan step-by-step. PS addresses sequencing but not completeness—the plan may omit implicit intents [6].
+
+### The Completeness Gap
+
+All existing strategies share a common assumption: the model correctly identifies all intents in the input prompt. This assumption fails for complex, multi-intent prompts—particularly those containing:
+
+- **Hedging language:** "maybe," "perhaps," "if possible," "also consider"
+- **Embedded conditionals:** "if X then also Y"
+- **Implied requirements:** "set up CI/CD" implies test execution, linting, build verification
+- **Conversational asides:** "oh and we'll need..." signals an afterthought the model may deprioritize
+- **Scope ambiguity:** "make sure everything works" requires decomposition to define "everything"
+
+PDE addresses this completeness gap by operating on the prompt itself, before any reasoning strategy is applied.
+
+## Analysis
+
+### The PDE Methodology
+
+PDE operates in three phases:
+
+#### Phase 1: Intent Extraction
+
+The complex prompt is analyzed for:
+
+**Primary Intents:** Directly stated, unhedged action items.
+```json
+[
+  {"intent": "Set up project with TypeScript", "confidence": "high", "explicit": true},
+  {"intent": "Add ESLint and Prettier", "confidence": "high", "explicit": true},
+  {"intent": "Write a basic README", "confidence": "high", "explicit": true}
+]
+```
+
+**Secondary Intents:** Hedged, implied, or conditionally stated items.
+```json
+[
+  {"intent": "Configure Husky for pre-commit hooks", "confidence": "medium", "marker": "maybe also"},
+  {"intent": "Set up Jest testing", "confidence": "medium", "marker": "probably need"},
+  {"intent": "Configure CI/CD pipeline", "confidence": "high", "explicit": true, "underdetermined": true}
+]
+```
+
+**Implicit Intents:** Requirements not stated but logically entailed.
+```json
+[
+  {"intent": "Create package.json with scripts", "derivedFrom": "TypeScript setup + tooling"},
+  {"intent": "Create tsconfig.json", "derivedFrom": "TypeScript setup"},
+  {"intent": "Define CI/CD scope (lint, test, build)", "derivedFrom": "CI/CD + all tools mentioned"}
+]
+```
+
+#### Phase 2: Dependency Mapping
+
+Extracted intents are analyzed for dependencies:
+
+```
+TypeScript setup ← ESLint config (needs tsconfig)
+TypeScript setup ← Jest config (needs ts-jest)
+ESLint + Prettier ← Husky pre-commit hooks (hooks run lint/format)
+All tooling ← CI/CD pipeline (pipeline runs all tools)
+All tooling ← README (documents all tools)
+```
+
+This dependency graph prevents execution ordering errors (e.g., configuring Husky before ESLint exists).
+
+#### Phase 3: Four Directions Organization
+
+Extracted and dependency-mapped intents are organized into a Four Directions action stack:
+
+**East (Vision/Initiation):** Understand the project requirements, establish the desired architecture, define what "done" looks like.
+
+**South (Analysis/Design):** Decompose into specific, executable tasks. This is where PDE's output resides—the structured decomposition.
+
+**West (Implementation/Testing):** Execute the tasks in dependency order, verifying each step.
+
+**North (Integration/Wisdom):** Review the complete result, verify all intents (including secondary and implicit) have been addressed, document the outcome.
+
+### Comparison with Existing Strategies
+
+| Strategy | Operates On | Addresses | Completeness |
+|----------|------------|-----------|-------------|
+| CoT | Reasoning process | Accuracy | No |
+| ToT | Solution exploration | Creativity | No |
+| Self-Consistency | Answer validation | Reliability | No |
+| DecomP | Question structure | Complexity | Partial |
+| Plan-and-Solve | Execution plan | Sequencing | Partial |
+| **PDE** | **Input prompt** | **Completeness** | **Yes** |
+
+PDE is complementary to, not competitive with, existing strategies. A system can first apply PDE to ensure all intents are captured, then apply CoT or ToT to reason about each extracted intent.
+
+### Hedging Language as Signal, Not Noise
+
+A distinctive contribution of PDE is its treatment of hedging language. Traditional NLP treats hedging ("maybe," "perhaps," "if possible") as uncertainty markers to be discounted. PDE treats them as **intent signals with reduced confidence**—the user wants the thing, but is expressing it with social softening or conditional framing.
+
+When a user says "maybe also configure Husky," they almost certainly want Husky configured—the "maybe" reflects conversational politeness or uncertainty about whether it's the right tool, not genuine indifference to the outcome. PDE captures this as a secondary intent with a confidence annotation, ensuring it is not dropped during execution.
+
+### The Decomposition Result Schema
+
+PDE produces a structured `DecompositionResult` object:
+
+```typescript
+interface DecompositionResult {
+  id: string;
+  timestamp: string;
+  originalPrompt: string;
+  primaryIntents: Intent[];
+  secondaryIntents: Intent[];
+  implicitIntents: Intent[];
+  contextRequirements: ContextRequirement[];
+  dependencies: Dependency[];
+  fourDirectionsStack: {
+    east: ActionItem[];   // Vision
+    south: ActionItem[];  // Analysis
+    west: ActionItem[];   // Implementation
+    north: ActionItem[];  // Integration
+  };
+  ambiguityFlags: AmbiguityFlag[];
+}
+```
+
+This schema is serialized as JSON and stored in a `.pde/` directory alongside the project, creating a persistent record of prompt decompositions that can be reviewed, edited, and versioned.
+
+### PDE as Completeness Safeguard
+
+The primary value proposition of PDE is not sophistication but **completeness.** In multi-mission agent sessions where a single prompt may contain dozens of intents spanning multiple domains, the risk of intent loss is the primary failure mode. PDE functions as a safeguard against this loss—a systematic check that everything the user asked for has been identified before execution begins.
+
+This is particularly critical in voice-transcription handoff scenarios, where speech-to-text produces raw verbatim text with conversational hedging, tangential asides, and implicit assumptions that text-based prompts typically refine away.
+
+## Implications for CoAiA.js
+
+PDE is the entry point of the CoAiA.js agent pipeline:
+
+1. **Session start decomposition.** Every agent session begins with PDE decomposition of the user's initial prompt, ensuring no intents are lost before work begins.
+2. **Structural tension chart generation.** PDE's output feeds directly into STC creation—primary intents become desired outcomes, current reality is assessed, and action steps are populated from the Four Directions stack.
+3. **MMOT completeness checks.** During evaluation, agents verify that all extracted intents (including secondary and implicit) have been addressed, using PDE's output as the completeness checklist.
+4. **Version-controlled decompositions.** PDE results stored in `.pde/` directories provide audit trails showing exactly how complex prompts were interpreted.
+5. **MCP integration.** The PDE engine is exposed as an MCP tool, enabling any MCP-compliant host to decompose prompts using the same methodology.
+
+## Conclusion
+
+Prompt Decomposition Engineering addresses a fundamental gap in the prompt engineering landscape: the completeness of intent extraction from complex, multi-intent prompts. By operating on the input prompt rather than the reasoning process, PDE complements existing strategies (CoT, ToT, DecomP) while solving a distinct problem. The methodology's systematic extraction of primary, secondary, and implicit intents—combined with dependency mapping and Four Directions organization—provides the completeness safeguard that complex agent sessions require.
+
+## References
+
+1. LearnPrompting. (2024). "Advanced Decomposition Techniques for Improved Prompting in LLMs." https://learnprompting.org/docs/advanced/decomposition/introduction
+2. Wei, J., et al. (2022). "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models." *NeurIPS 2022*.
+3. Yao, S., et al. (2023). "Tree of Thoughts: Deliberate Problem Solving with Large Language Models." *NeurIPS 2023*.
+4. Wang, X., et al. (2022). "Self-Consistency Improves Chain of Thought Reasoning in Language Models." *ICLR 2023*.
+5. Khot, T., et al. (2022). "Decomposed Prompting: A Modular Approach for Solving Complex Tasks." *ICLR 2023*.
+6. Wang, L., et al. (2023). "Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning." *ACL 2023*.
+7. Oxen.ai. (2024). "The Prompt Report Part 2: Plan and Solve, Tree of Thought, and Decomposition Prompting." https://ghost.oxen.ai/the-prompt-report-part-2-thought-generation-tree-of-thought-and-decomposition-prompting/
+8. CalmOps. (2024). "Prompt Engineering Patterns: CoT, ReAct, and ToT." https://calmops.com/ai/prompt-engineering-patterns-cot-react-tot/
+9. Exploratio Journal. (2024). "Zooming-in On Prompting: A Comparative Study." https://exploratiojournal.com/zooming-in-on-prompting/
+10. Coupler.io. (2024). "Advanced Prompting Techniques for Complex AI Reasoning." https://blog.coupler.io/advanced-prompting-techniques/

package/articles/academic/structural-tension-in-ai-agents.md

@@ -0,0 +1,134 @@
+# Structural Tension in AI Agents: Robert Fritz's Methodology Applied to Autonomous Goal Management
+
+> Academic brief for the CoAiA.js project — Structural tension charts as computational data structures for tracking desired outcomes versus current reality in autonomous AI agent systems.
+
+## Abstract
+
+Autonomous AI agents face a fundamental challenge: maintaining coherent progress toward goals while continuously adapting to evolving environments. This paper examines how Robert Fritz's structural tension methodology—originally developed for human creative processes—can be formalized as a computational framework for AI agent goal management. We define structural tension charts (STCs) as first-class data structures encoding the gap between a desired outcome and an assessed current reality, with tension resolution driving agent behavior. Unlike traditional goal-stack or utility-maximization approaches, structural tension provides a creative orientation that sustains forward momentum without the oscillatory patterns characteristic of problem-solving architectures. We analyze the formal properties of STCs, their implementation as JSONL-backed state machines, and their implications for agent autonomy, self-correction, and telescoping goal decomposition. The framework is evaluated in the context of CoAiA.js, a JavaScript runtime for structurally-tensioned AI agents.
+
+## Introduction
+
+The design of AI agent goal management systems has historically drawn from planning literature (STRIPS, HTN), reinforcement learning (reward maximization), and behavioral architectures (subsumption, BDI). While these approaches have proven effective in constrained domains, they share a common structural limitation: they are fundamentally problem-solving architectures, oriented toward the elimination of undesirable states rather than the creation of desired ones.
+
+Robert Fritz, in *The Path of Least Resistance* (1989) and *Creating* (1991), identified a critical distinction between two orientations toward action. Problem-solving orientation generates energy by moving away from what is unwanted; creative orientation generates energy by moving toward what is desired. Fritz demonstrated that problem-solving architectures produce oscillatory dynamics—as the problem diminishes, so does motivation, leading to cyclical regression. Creative orientation, by contrast, produces advancing dynamics through structural tension: the sustained gap between a clearly articulated desired outcome and an honestly assessed current reality [1].
+
+This paper formalizes structural tension as a computational construct for AI agent systems. We argue that encoding desired outcomes and current reality as co-evolving data structures—with the tension between them as the primary driver of agent behavior—produces agents with superior goal coherence, self-correction capabilities, and resistance to the oscillatory patterns that plague reactive architectures.
+
+## Background
+
+### Fritz's Structural Tension Model
+
+The structural tension model rests on three axioms:
+
+1. **Tension seeks resolution.** A system with a gap between desired outcome and current reality will tend toward resolution of that gap, following the path of least resistance.
+2. **The path of least resistance is determined by underlying structure.** The arrangement of elements in a system determines how tension resolves—whether through advancement toward the desired outcome or oscillation between states.
+3. **Creative orientation produces advancing structures.** When the desired outcome is held constant and current reality is honestly assessed, tension resolves through advancement. When the problem is the primary reference point, tension resolves through oscillation [1][2].
+
+Fritz's methodology requires practitioners to: (a) clearly articulate what they want to create, (b) honestly assess current reality relative to that vision, and (c) hold both simultaneously, allowing the structural tension to drive action [3].
+
+### Existing Agent Goal Architectures
+
+Traditional agent architectures encode goals in several ways:
+
+- **Goal stacks** (STRIPS/PDDL): Goals as predicate conditions to satisfy. No notion of ongoing tension; goals are binary (achieved/not achieved).
+- **Utility functions** (RL/MDPs): Goals as reward signals to maximize. Susceptible to reward hacking and lacks semantic richness.
+- **BDI architectures**: Beliefs-Desires-Intentions model maintains goal hierarchies but lacks the structural tension dynamic that prevents oscillation.
+- **Behavior trees**: Reactive architectures that respond to conditions without maintaining creative tension toward outcomes [4].
+
+None of these architectures encode the dual-reference-point structure (desired outcome + current reality) that Fritz identifies as essential for sustained creative advancement.
+
+## Analysis
+
+### Structural Tension Charts as Data Structures
+
+We define a Structural Tension Chart (STC) as a tuple:
+
+```
+STC = (D, R, A[], T, Δ)
+```
+
+Where:
+- **D** (Desired Outcome): A natural-language description of the target state, held constant unless explicitly revised.
+- **R** (Current Reality): A timestamped, append-only log of observations about the present state. Critically, R must be an honest assessment—not a readiness statement or aspiration.
+- **A[]** (Action Steps): An ordered set of intermediate goals, each of which is itself a telescoped STC.
+- **T** (Tension): The computed gap between D and R, which drives agent decision-making.
+- **Δ** (Delta History): A temporal record of reality updates, enabling the agent to assess whether it is advancing or oscillating.
+
+The key innovation is that **tension is not a problem to solve but a creative force to harness**. The agent does not minimize a loss function; it moves toward a desired creation while continuously updating its understanding of reality.
+
+### Telescoping: Recursive Goal Decomposition
+
+A critical feature of structural tension methodology is telescoping—the ability to decompose any action step into its own full STC. This creates a recursive hierarchy:
+
+```
+Master STC
+  ├── Action Step 1 → Telescoped STC₁
+  │     ├── Sub-action 1a → Telescoped STC₁ₐ
+  │     └── Sub-action 1b → Telescoped STC₁ᵦ
+  ├── Action Step 2 → Telescoped STC₂
+  └── Action Step 3 → Telescoped STC₃
+```
+
+Each telescoped STC maintains its own desired outcome, current reality, and tension. This structure enables agents to work at multiple levels of abstraction simultaneously, focusing on immediate sub-tasks while maintaining alignment with higher-level creative intent.
+
+### Preventing Oscillation: The Structural Advantage
+
+Fritz observed that problem-solving systems oscillate because their energy source (the problem) diminishes as progress is made. In computational terms, a reward-minimization agent that reduces error from 0.8 to 0.2 experiences diminishing gradient—the "problem" is mostly "solved," and momentum collapses.
+
+Structural tension charts prevent this because:
+
+1. **The desired outcome remains constant.** The vision does not diminish as reality improves.
+2. **Current reality is continuously re-assessed.** New observations may reveal previously unknown gaps, maintaining or even increasing tension.
+3. **Completion is binary and explicit.** An action step is marked complete through deliberate assessment (the Managerial Moment of Truth), not through gradient convergence.
+
+### Implementation: JSONL-Backed State Machines
+
+In the CoAiA.js implementation, STCs are stored as append-only JSONL (JSON Lines) records:
+
+```jsonl
+{"type":"chart","id":"chart_001","desiredOutcome":"Production-ready MCP server","currentReality":"Prototype exists with 3 tools; no tests, no error handling","createdAt":"2026-03-10T14:00:00Z"}
+{"type":"action","chartId":"chart_001","name":"chart_001_action_1","title":"Implement error handling","currentReality":"No try-catch patterns; errors crash the process"}
+{"type":"reality_update","chartId":"chart_001","observation":"Added error boundaries to tool dispatch; 2 of 5 tools now handle errors gracefully","timestamp":"2026-03-10T16:30:00Z"}
+{"type":"completion","actionName":"chart_001_action_1","timestamp":"2026-03-10T18:00:00Z"}
+```
+
+The append-only format ensures that no historical state is lost—every observation, update, and completion is preserved. This enables temporal analysis of tension dynamics: is the agent advancing, oscillating, or stalled?
+
+### Tension as Agent Decision Driver
+
+Rather than selecting actions through utility maximization or plan execution, a structurally-tensioned agent operates through the following cycle:
+
+1. **Assess tension:** Compare desired outcome against current reality across all active STCs.
+2. **Select highest-tension chart:** The STC with the greatest gap between D and R receives attention.
+3. **Identify next action:** Within the selected chart, find the next incomplete action step.
+4. **Execute and observe:** Perform the action and update current reality with honest observations.
+5. **Evaluate via MMOT:** Apply the Managerial Moment of Truth to assess whether the action advanced the chart or revealed new gaps.
+
+This cycle naturally produces depth-first progress on high-priority goals while enabling context switching when new information shifts the tension landscape.
+
+## Implications for CoAiA.js
+
+CoAiA.js implements structural tension charts as its primary goal management primitive. The implications are:
+
+1. **Agent sessions are organized around STCs**, not task lists. Every agent session begins with chart creation—articulating a desired outcome and honestly assessing current reality.
+2. **Progress is measured by reality advancement**, not task completion counts. An agent that completes 10 tasks but fails to advance current reality toward the desired outcome has not made meaningful progress.
+3. **Telescoping enables multi-scale operation.** Agents can decompose complex goals into nested STCs, each maintaining its own tension dynamics, while the master chart provides coherence.
+4. **JSONL storage provides full auditability.** Every decision, observation, and completion is recorded, enabling post-hoc analysis of agent behavior and tension dynamics.
+5. **The MMOT cycle provides self-correction.** Agents can detect oscillation by analyzing their Δ history and adjust their approach when advancement stalls.
+
+## Conclusion
+
+Structural tension charts offer a fundamentally different paradigm for AI agent goal management—one rooted in creative orientation rather than problem-solving. By encoding the gap between desired outcomes and current reality as a first-class data structure, and by driving agent behavior through tension resolution rather than reward maximization, we obtain agents that advance coherently toward creative goals without the oscillatory dynamics that plague reactive architectures. The formalization presented here provides a foundation for building AI systems that create rather than merely optimize.
+
+## References
+
+1. Fritz, R. (1989). *The Path of Least Resistance: Learning to Become the Creative Force in Your Own Life*. Fawcett Columbine.
+2. Fritz, R. (1999). *The Path of Least Resistance for Managers*. Berrett-Koehler Publishers.
+3. Foss, L. "Structural Tension Model." https://www.larafoss.com/structural-tension
+4. Wooldridge, M. (2009). *An Introduction to MultiAgent Systems*. 2nd ed. Wiley.
+5. Fritz, R. "Tension Seeks Resolution." Robert Fritz Inc. https://www.robertfritz.com/wp/principles/tension-seeks-resolution/
+6. Think-2-Thrive. (2024). "Leading with Creative Tension." https://think-2-thrive.com/2024/12/02/blog-55-leading-with-creative-tension/
+7. Thwink.org. "Structural Tension." https://www.thwink.org/soft/info/process/structural/StructuralTension.html
+8. Senge, P. (1990). *The Fifth Discipline: The Art & Practice of the Learning Organization*. Doubleday.
+9. Rao, A. S., & Georgeff, M. P. (1995). "BDI Agents: From Theory to Practice." *Proceedings of the First International Conference on Multi-Agent Systems (ICMAS-95)*.
+10. Fritz, R., & Bodaken, B. (2006). *The Managerial Moment of Truth*. Free Press.