coaiajs 0.1.0

package/articles/surveys/agent-orchestration-survey.md

@@ -0,0 +1,186 @@
+# Survey of Multi-Agent Orchestration Patterns: AutoGen, CrewAI, LangGraph, and MCP
+
+> Academic survey for the CoAiA.js project — How AI agents coordinate, delegate, and share context across leading orchestration frameworks and the emergent role of MCP as a universal interoperability layer.
+
+## Abstract
+
+The multi-agent AI ecosystem has fragmented into distinct orchestration paradigms: role-based teams (CrewAI), graph-based state machines (LangGraph), conversation-driven negotiation (AutoGen/AG2), and protocol-standardized tool invocation (MCP). This survey examines the architectural patterns, coordination mechanisms, and operational trade-offs of these four approaches to multi-agent orchestration. We analyze each framework's model for agent specialization, inter-agent communication, context sharing, and error recovery. Our findings reveal a convergence toward hybrid architectures where MCP provides the universal tool interface, while framework-specific patterns handle agent coordination logic. The survey situates CoAiA.js's Four Directions orchestration model within this landscape, demonstrating how structural tension methodology provides an alternative to both role-based and graph-based coordination that naturally prevents the oscillatory patterns common in complex multi-agent workflows.
+
+## Introduction
+
+The transition from single-agent to multi-agent AI systems introduces coordination challenges that mirror those in distributed computing and organizational management: how do agents divide labor, share context, handle failures, and maintain coherent progress toward shared goals? [1]
+
+The 2024–2025 period has seen rapid proliferation of orchestration frameworks, each embodying different assumptions about how agents should interact. This survey examines the four dominant paradigms, identifies their structural properties, and evaluates their implications for the design of CoAiA.js's multi-agent capabilities.
+
+## Survey of Orchestration Patterns
+
+### 1. Role-Based Team Orchestration: CrewAI
+
+**Architecture:** Agents are defined as team members with explicit roles (Researcher, Writer, Reviewer), goals, tools, and behavioral constraints. A "crew" is assembled from these role-defined agents and given a task sequence to execute [2][3].
+
+**Coordination Model:**
+```python
+researcher = Agent(role="Senior Researcher", goal="Find comprehensive information", tools=[search, scrape])
+writer = Agent(role="Technical Writer", goal="Create clear documentation", tools=[write, format])
+crew = Crew(agents=[researcher, writer], tasks=[research_task, writing_task], process=Process.sequential)
+```
+
+**Communication Pattern:** Primarily sequential task handoff—the output of one agent becomes the input of the next. Limited support for parallel execution and inter-agent negotiation.
+
+**Strengths:**
+- Intuitive mental model (mirrors human team organization)
+- Fastest prototyping and lowest learning curve
+- Effective for linear business workflows
+- Clean separation of concerns through role specialization
+
+**Weaknesses:**
+- Limited control flow: branching, looping, and conditional logic are constrained
+- Susceptible to "agent loops" where agents repeatedly invoke each other without progress
+- Low determinism: identical inputs can produce different execution paths
+- Debugging is challenging: agent decisions are opaque [4][5]
+
+**Structural Tension Analysis:** CrewAI operates without explicit structural tension. Goals are stated but current reality is not formally tracked. This makes CrewAI susceptible to the oscillation pattern: agents work toward goals, partially achieve them, lose momentum, and re-engage when prompted.
+
+### 2. Graph-Based State Machine Orchestration: LangGraph
+
+**Architecture:** Workflows are modeled as directed graphs where nodes represent processing steps (which may involve agents) and edges represent transitions between steps. State is explicitly managed and passed between nodes [6][7].
+
+**Coordination Model:**
+```python
+graph = StateGraph(AgentState)
+graph.add_node("research", research_node)
+graph.add_node("write", write_node)
+graph.add_node("review", review_node)
+graph.add_edge("research", "write")
+graph.add_conditional_edges("review", should_revise, {"revise": "write", "approve": END})
+```
+
+**Communication Pattern:** State-passing through a shared state object. Each node reads from and writes to the state, enabling complex branching, looping, and conditional logic.
+
+**Strengths:**
+- Highest control and determinism among frameworks
+- Explicit branching, looping, error recovery, and conditional logic
+- Production-grade reliability (~94% accuracy in benchmarks)
+- Full visibility into execution state at every point
+- Natural fit for complex, multi-step workflows with failure recovery [8]
+
+**Weaknesses:**
+- Steepest learning curve: requires understanding of state machines and graph theory
+- Most verbose code for simple workflows
+- Tightly coupled to LangChain ecosystem
+- Over-engineering risk for straightforward sequential tasks
+
+**Structural Tension Analysis:** LangGraph's state machine model can encode structural tension: the state object can carry desired outcome and current reality, and conditional edges can check tension resolution. However, this requires explicit implementation—it is not a native feature.
+
+### 3. Conversation-Driven Orchestration: AutoGen (AG2)
+
+**Architecture:** Agents communicate through structured conversations—rounds of messages where each agent contributes based on its perspective. Coordination emerges from the conversation rather than being imposed by a workflow graph [9][10].
+
+**Coordination Model:**
+```python
+assistant = AssistantAgent("assistant", llm_config=llm_config)
+critic = AssistantAgent("critic", system_message="Critique code quality")
+user_proxy = UserProxyAgent("user", code_execution_config={"work_dir": "coding"})
+groupchat = GroupChat(agents=[user_proxy, assistant, critic], messages=[], max_round=12)
+```
+
+**Communication Pattern:** Round-robin or dynamic turn-taking in group chats. Agents see the full conversation history and contribute based on their system messages and observed context.
+
+**Strengths:**
+- Most natural model for collaborative reasoning and negotiation
+- Flexible: agent composition can change dynamically
+- Strong for human-in-the-loop workflows
+- Effective for research, brainstorming, and iterative refinement
+- AG2 (successor) adds enterprise reliability features [11]
+
+**Weaknesses:**
+- Least deterministic: conversation dynamics are inherently unpredictable
+- Context overflow risk: long conversations exceed context windows
+- Debugging difficulty: tracing which conversational turn caused which outcome
+- Performance unpredictability: conversation length varies significantly
+
+**Structural Tension Analysis:** AutoGen's conversational model naturally surfaces tension—critics identify gaps between desired and actual output. However, this tension is implicit in conversation rather than explicitly tracked, making it difficult to measure advancement vs. oscillation.
+
+### 4. Protocol-Standardized Tool Invocation: MCP
+
+**Architecture:** MCP is not an orchestration framework but a **communication protocol** that standardizes how agents invoke tools. Unlike CrewAI, LangGraph, and AutoGen, MCP does not prescribe coordination patterns—it provides the infrastructure layer upon which coordination is built [12][13].
+
+**Coordination Model:** MCP defines tool discovery (tools/list), tool invocation (tools/call), resource access (resources/read), and prompt provision (prompts/get) through JSON-RPC 2.0 messages over stdio or HTTP transport.
+
+**Strengths:**
+- Universal: any framework can use MCP for tool invocation
+- Dynamic tool discovery: agents learn available capabilities at runtime
+- Human-in-the-loop: built-in approval gates for sensitive operations
+- Framework-agnostic: works with CrewAI, LangGraph, AutoGen, or custom systems
+
+**Weaknesses:**
+- Not an orchestration framework: does not handle agent coordination, context sharing, or workflow management
+- Young ecosystem: tooling and community still developing
+- Potential overhead: JSON-RPC adds latency compared to direct function calls
+
+**Structural Tension Analysis:** MCP provides the tool interface through which structural tension charts can be created, read, and updated. MCP servers can expose STC operations as tools, making structural tension accessible to any MCP-compliant agent.
+
+### Comparative Analysis
+
+| Dimension | CrewAI | LangGraph | AutoGen/AG2 | MCP |
+|-----------|--------|-----------|-------------|-----|
+| **Paradigm** | Role-based teams | Graph state machine | Conversation | Protocol |
+| **Control** | Low–Medium | Very High | Medium | N/A (infra) |
+| **Determinism** | Low | High | Low | N/A |
+| **Learning Curve** | Low | High | Medium | Low |
+| **Best For** | Prototyping, business | Production, complex | Research, negotiation | Tool interop |
+| **STC Support** | None native | Possible via state | Implicit in conversation | Tool interface |
+| **Oscillation Risk** | High | Low (explicit control) | Medium | N/A |
+
+### Emerging Pattern: Hybrid Architectures
+
+The most effective multi-agent systems in 2025 combine multiple paradigms:
+
+1. **MCP as universal tool layer.** All external tool invocations go through MCP, providing standardized access, observability, and security.
+2. **LangGraph for critical workflows.** Mission-critical, multi-step processes use graph-based orchestration for determinism and error recovery.
+3. **CrewAI for team simulation.** Business workflows with clear role divisions use role-based orchestration for intuitive design.
+4. **AutoGen for collaborative reasoning.** Research, brainstorming, and negotiation tasks use conversational orchestration for emergent insights.
+
+### The Four Directions Alternative
+
+CoAiA.js proposes a fifth paradigm: **directional orchestration** based on the Medicine Wheel framework:
+
+- **East Agent:** Vision articulation and creative ideation
+- **South Agent:** Analysis, research, and prompt decomposition (PDE)
+- **West Agent:** Implementation and iterative building
+- **North Agent:** Evaluation (MMOT), documentation, and wisdom synthesis
+
+This model is structurally distinct from role-based, graph-based, or conversation-based orchestration:
+
+- Unlike CrewAI roles, directional agents represent **phases of creative process**, not job descriptions
+- Unlike LangGraph graphs, the Four Directions form a **cycle**, not a directed acyclic graph
+- Unlike AutoGen conversations, handoffs between directions are **structurally motivated** by the completion of each phase's contribution
+- Structural tension charts provide the coordination mechanism: each direction advances the chart, and the tension between desired outcome and current reality drives the cycle forward
+
+## Implications for CoAiA.js
+
+1. **MCP as tool layer.** CoAiA.js uses MCP for all external tool invocations, ensuring framework-agnostic tool access.
+2. **Four Directions as orchestration.** Agent coordination follows the directional cycle, not role-based teams or conversation rounds.
+3. **Structural tension as coordination.** The STC's tension measurement drives agent scheduling—the direction with the highest contribution potential receives attention.
+4. **Hybrid compatibility.** CoAiA.js's directional agents can operate within LangGraph workflows, CrewAI teams, or AutoGen conversations when integration with external frameworks is needed.
+5. **Oscillation prevention.** The structural tension chart's advancing structure prevents the oscillation that plagues role-based and conversation-based systems.
+
+## Conclusion
+
+Multi-agent orchestration in 2025 is characterized by framework proliferation and emerging hybridization. Each paradigm—role-based, graph-based, conversational, and protocol-based—offers distinct trade-offs in control, determinism, and expressiveness. CoAiA.js's Four Directions orchestration model adds a fifth paradigm rooted in structural tension methodology, providing cyclical, balanced coordination that naturally resists oscillation. The convergence on MCP as a universal tool interface layer suggests that orchestration frameworks will increasingly specialize in coordination logic while delegating tool invocation to the protocol layer.
+
+## References
+
+1. DataCamp. (2024). "CrewAI vs LangGraph vs AutoGen: Choosing the Right Multi-Agent Framework." https://www.datacamp.com/tutorial/crewai-vs-langgraph-vs-autogen
+2. TutorialQ. (2025). "CrewAI vs LangGraph vs AutoGen." https://tutorialq.com/agents/frameworks/crewai-vs-langgraph-vs-autogen
+3. Youngju.dev. (2026). "Comparing LLM Agent Frameworks." https://www.youngju.dev/blog/llm/2026-03-09-llm-agent-framework-autogen-crewai-langgraph-comparison.en
+4. Amplework. (2025). "LangGraph vs AutoGen vs CrewAI." https://www.amplework.com/blog/langgraph-vs-autogen-vs-crewai-multi-agent-framework/
+5. Braincuber. (2025). "CrewAI vs AutoGen vs LangGraph: Framework Comparison." https://www.braincuber.com/blog/crewai-vs-autogen-vs-langgraph-multi-agent-framework-comparison
+6. Meta Intelligence. (2025). "The Complete Guide to AI Agent Development." https://www.meta-intelligence.tech/en/insight-ai-agent-frameworks
+7. SoftwareSeni. (2025). "Navigating the Multi-Agent Framework Landscape." https://www.softwareseni.com/navigating-the-multi-agent-framework-landscape-from-crewai-to-langgraph-to-autogen-and-beyond/
+8. Infinite Lambda. (2025). "CrewAI, AutoGen, Vertex AI, and LangGraph Comparison." https://infinitelambda.com/compare-crewai-autogen-vertexai-langgraph/
+9. Datagrom. (2025). "Top 3 Trending Agentic AI Frameworks." https://www.datagrom.com/data-science-machine-learning-ai-blog/langgraph-vs-autogen-vs-crewai-comparison-agentic-ai-frameworks
+10. Tagline Infotech. (2025). "Choosing the Right AI Agent Framework." https://taglineinfotech.com/blog/langgraph-vs-crewai-vs-autogen/
+11. AG2 (AutoGen successor). https://github.com/ag2ai/ag2
+12. Anthropic. (2024). "Introducing the Model Context Protocol." https://www.anthropic.com/news/model-context-protocol
+13. Model Context Protocol Specification. (2025). https://modelcontextprotocol.io/specification/2025-03-26

package/articles/surveys/knowledge-graph-storage-survey.md

@@ -0,0 +1,204 @@
+# Survey of Knowledge Graph Storage Approaches for AI Agent Systems
+
+> Academic survey for the CoAiA.js project — Comparative analysis of property graphs, RDF triples, JSONL entity-relation models, and vector embeddings as lightweight, agent-compatible knowledge representation formats.
+
+## Abstract
+
+AI agent systems require persistent knowledge representation that balances expressiveness, performance, and operational simplicity. This survey examines four primary approaches to knowledge graph storage—property graphs, RDF triple stores, JSONL entity-relation models, and vector embedding databases—with particular focus on their suitability for lightweight, agent-compatible deployments. We analyze each approach across seven dimensions: expressive power, query capabilities, operational complexity, portability, temporal modeling, concurrency support, and ecosystem maturity. Our findings indicate that no single approach dominates all dimensions; rather, the optimal choice depends on the agent's operational context. For single-agent session workloads with moderate graph sizes (under 100K entities), JSONL entity-relation models offer the best balance of simplicity and capability. For multi-agent systems requiring concurrent access and complex traversals, property graph databases remain superior. Vector embeddings complement rather than replace structured graph storage, excelling at semantic retrieval within graph-structured knowledge. The survey concludes with recommendations for hybrid architectures that combine multiple storage approaches based on workload characteristics.
+
+## Introduction
+
+Knowledge graphs have emerged as the preferred representation for structured knowledge in AI systems, encoding entities, their properties, and the relationships between them in a format amenable to both human understanding and machine reasoning. The knowledge graph storage landscape, however, presents a dizzying array of options—from enterprise-grade graph databases to lightweight file-based formats, from semantically-rich RDF stores to embedding-only vector databases [1][2].
+
+For AI agent developers, the selection criteria differ significantly from traditional enterprise knowledge management. Agents need:
+- **Rapid deployment:** Zero-config or minimal-config storage that works immediately
+- **Session-scoped data:** Most agent knowledge is session-specific, not enterprise-wide
+- **Temporal evolution:** Knowledge evolves throughout a session; history matters
+- **Portability:** Storage must be transferable between environments
+- **Moderate scale:** Agent sessions typically produce thousands, not millions, of facts [3]
+
+This survey evaluates the major storage approaches against these agent-specific requirements.
+
+## Survey of Approaches
+
+### 1. Property Graph Databases
+
+**Representative systems:** Neo4j, Memgraph, KuzuDB (archived, forked), FalkorDB, Amazon Neptune
+
+**Data Model:** Nodes and edges, each with typed key-value properties. Nodes represent entities; edges represent relationships. Both nodes and edges can carry arbitrary property maps.
+
+```cypher
+CREATE (s:Server {name: "mcp-server", version: "2.0"})
+CREATE (l:Library {name: "langfuse", license: "MIT"})
+CREATE (s)-[:DEPENDS_ON {since: "2025-01"}]->(l)
+```
+
+**Query Language:** Cypher (Neo4j, Memgraph, KuzuDB) or Gremlin (Apache TinkerPop). Both support pattern matching, path queries, and graph algorithms.
+
+**Strengths:**
+- Native graph traversal with optimized algorithms (shortest path, community detection, centrality)
+- Flexible schema evolution—new properties and relationships added without migration
+- Mature ecosystem with visualization tools, bulk import, and enterprise features
+- KuzuDB (embedded fork by Vela Engineering) claims 374x path query speedup vs. Neo4j for embedded workloads [4]
+
+**Weaknesses:**
+- Operational overhead: Neo4j requires JVM server; Memgraph requires separate process
+- Licensing complexity: Neo4j Community vs. Enterprise; varying open-source commitments
+- Heavyweight for session-scoped data: designed for persistent, multi-user access patterns
+- Not naturally append-only; mutations can lose temporal history without explicit versioning
+
+**Agent Suitability:** Best for multi-agent systems requiring concurrent access, complex graph queries, or enterprise-scale knowledge. Overkill for single-agent sessions.
+
+### 2. RDF Triple Stores
+
+**Representative systems:** Apache Jena/Fuseki, GraphDB, Blazegraph, Amazon Neptune (RDF mode), Virtuoso
+
+**Data Model:** Subject-Predicate-Object triples with URI-based identification, conforming to W3C standards. Supports ontological reasoning through RDFS and OWL.
+
+```turtle
+<http://coaia.js/server/mcp> <http://coaia.js/schema/dependsOn> <http://coaia.js/library/langfuse> .
+<http://coaia.js/server/mcp> <http://coaia.js/schema/version> "2.0" .
+<http://coaia.js/library/langfuse> <http://coaia.js/schema/license> "MIT" .
+```
+
+**Query Language:** SPARQL, supporting complex graph pattern matching, aggregation, and federated queries across multiple endpoints.
+
+**Strengths:**
+- Formal semantics enabling automated reasoning and inference
+- Interoperability through standardized vocabularies and ontologies
+- Federated query capability across distributed data sources
+- W3C standardization ensures long-term ecosystem stability [5][6]
+
+**Weaknesses:**
+- Verbose data representation; high overhead per fact
+- SPARQL learning curve significantly steeper than Cypher
+- Performance challenges for analytics and complex traversals at scale
+- Schema rigidity through ontological constraints can impede agile development
+- Few lightweight/embedded implementations suitable for agent deployment
+
+**Agent Suitability:** Best when semantic reasoning, data interoperability, or integration with linked data ecosystems is required. Poor fit for lightweight, session-scoped agent memory.
+
+### 3. JSONL Entity-Relation Models
+
+**Representative systems:** CoAiA memory (coaia-narrative), Memento MCP, custom implementations
+
+**Data Model:** Line-delimited JSON where each line encodes an entity, relation, or observation. Typically uses a `type` field for discrimination:
+
+```jsonl
+{"type":"entity","name":"mcp_server","entityType":"component","observations":["Handles tool dispatch"]}
+{"type":"relation","from":"mcp_server","to":"langfuse","relationType":"depends_on"}
+{"type":"observation","entityName":"mcp_server","content":"Added v2 transport support","timestamp":"2026-03-10T14:00:00Z"}
+```
+
+**Query Mechanism:** No native query language. Queries are implemented through:
+- Full file load into in-memory graph structure
+- Streaming filter (grep, jq) for simple lookups
+- Application-level query APIs built on top of in-memory data
+
+**Strengths:**
+- Zero operational overhead: no server, no driver, no configuration
+- Natural append-only semantics: history is never lost
+- Human-readable and debuggable with standard text tools
+- Git-friendly: clean diffs, version-controllable
+- Portable: copy a single file to transfer knowledge
+- Schema-flexible: new entity and relation types added without migration [7]
+
+**Weaknesses:**
+- No native query language; all queries require application code
+- Linear scan for complex queries without in-memory indexing
+- No concurrent write safety without external locking
+- No built-in integrity constraints or validation
+- Performance degrades for large graphs (>100K records) without indexing
+
+**Agent Suitability:** Excellent for single-agent session workloads with moderate graph sizes. The dominant choice for development, edge deployment, and scenarios prioritizing simplicity over query power.
+
+### 4. Vector Embedding Databases
+
+**Representative systems:** Pinecone, Weaviate, Chroma, Milvus, Qdrant, pgvector
+
+**Data Model:** Dense vector representations of entities, with metadata for filtering. Each record is an embedding (typically 256–4096 dimensions) associated with source text and structured metadata.
+
+```json
+{
+  "id": "doc_001",
+  "embedding": [0.012, -0.034, 0.891, ...],
+  "metadata": {"source": "mcp_server", "type": "documentation"},
+  "text": "The MCP server handles JSON-RPC 2.0 tool invocations..."
+}
+```
+
+**Query Mechanism:** Approximate Nearest Neighbor (ANN) search returning top-k results by cosine similarity or other distance metrics, with optional metadata filtering.
+
+**Strengths:**
+- Semantic search: find conceptually similar entities regardless of lexical overlap
+- Integration with LLM workflows: embeddings are native to the LLM pipeline
+- Scalable to millions of vectors with sub-millisecond search
+- Effective for Retrieval-Augmented Generation (RAG) patterns [8]
+
+**Weaknesses:**
+- No explicit relational structure: relationships must be inferred from proximity
+- Loss of precision: embedding compression loses fine-grained factual detail
+- No temporal modeling: similarity search doesn't naturally order by time
+- Embedding model dependency: changing the embedding model invalidates all vectors
+- Not a knowledge graph: lacks the entity-relation structure essential for agent reasoning
+
+**Agent Suitability:** Excellent as a complementary retrieval layer within a graph-structured knowledge system. Should not be used as the sole knowledge representation for agents that need explicit relational reasoning.
+
+## Comparative Analysis
+
+### Seven-Dimension Comparison
+
+| Dimension | Property Graph | RDF Triple | JSONL E-R | Vector DB |
+|-----------|---------------|------------|-----------|-----------|
+| **Expressive Power** | High | Very High | Moderate | Low (semantic only) |
+| **Query Capability** | High (Cypher) | High (SPARQL) | Low (app code) | Moderate (ANN+filter) |
+| **Operational Complexity** | High | High | Minimal | Moderate |
+| **Portability** | Low | Moderate | Very High | Low |
+| **Temporal Modeling** | Manual | Manual | Native (append) | Manual |
+| **Concurrency** | High (ACID) | Moderate | Low (single writer) | Moderate |
+| **Ecosystem Maturity** | High | High | Low | Growing |
+
+### Workload-Based Recommendations
+
+**Single-agent session memory (dominant case):**
+→ JSONL entity-relation model. Zero-config, portable, temporally-native, adequate performance.
+
+**Multi-agent shared knowledge:**
+→ Property graph (KuzuDB embedded or Neo4j). Concurrent access, graph algorithms, path queries.
+
+**Semantic retrieval within agent context:**
+→ Vector database as retrieval layer, with JSONL or property graph as structural backbone.
+
+**Knowledge interoperability across systems:**
+→ RDF triple store. Standardized vocabularies enable cross-system integration.
+
+**Hybrid agent architecture:**
+→ JSONL for session state + vector DB for semantic retrieval + property graph for persistent cross-session knowledge.
+
+## Implications for CoAiA.js
+
+CoAiA.js adopts a layered storage architecture based on this survey:
+
+1. **Primary storage: JSONL entity-relation.** Session state, structural tension charts, and agent observations are stored in append-only JSONL files.
+2. **Semantic retrieval: Optional vector layer.** When enabled, entity observations are embedded and stored in a vector index for semantic search.
+3. **Cross-session knowledge: Optional graph database.** For multi-agent deployments, a property graph database can aggregate knowledge across sessions.
+4. **Export capability: RDF.** For interoperability with external knowledge systems, JSONL can be exported to RDF triples.
+
+This layered approach ensures minimal operational complexity for simple deployments while enabling richer capabilities when needed.
+
+## Conclusion
+
+The knowledge graph storage landscape offers no universal solution—each approach optimizes for different dimensions of the expressiveness-simplicity trade-off. For AI agent systems, where operational simplicity and session-scoped temporal modeling are paramount, JSONL entity-relation models provide the best default choice, with property graphs, vector databases, and RDF stores serving as complementary layers for specific capability needs.
+
+## References
+
+1. Neo4j. (2024). "RDF Triple Stores vs. Property Graphs." https://neo4j.com/blog/knowledge-graph/rdf-vs-property-graphs-knowledge-graphs/
+2. Enterprise Knowledge. (2024). "Cutting Through the Noise: An Introduction to RDF & LPG Graphs." https://enterprise-knowledge.com/cutting-through-the-noise-an-introduction-to-rdf-lpg-graphs/
+3. Graphlit Blog. (2024). "Survey of AI Agent Memory Frameworks." https://www.graphlit.com/blog/survey-of-ai-agent-memory-frameworks
+4. Vela Partners. (2025). "KuzuDB for Production AI Agents." https://www.vela.partners/blog/kuzudb-ai-agent-memory-graph-database
+5. Ontotext. (2024). "Choosing A Graph Data Model." https://www.ontotext.com/blog/choosing-a-graph-data-model-to-best-serve-your-use-case/
+6. TigerGraph. (2024). "RDF vs. Property Graph." https://www.tigergraph.com/blog/rdf-vs-property-graph-choosing-the-right-foundation-for-knowledge-graphs/
+7. Memento MCP. (2024). "A Knowledge Graph Memory System for LLMs." https://github.com/gannonh/memento-mcp
+8. SAP Community. (2025). "Choosing Between Knowledge Graphs and Property Graphs in SAP HANA Cloud." https://community.sap.com/t5/technology-blog-posts-by-sap/choosing-between-knowledge-graphs-and-property-graphs-in-sap-hana-cloud-and/ba-p/14074575
+9. Memgraph. (2024). "LPG vs. RDF." https://memgraph.com/docs/data-modeling/graph-data-model/lpg-vs-rdf
+10. DataWalk. (2024). "Best of Property Graph & RDF for Powerful Analytics." https://datawalk.com/property-graph-vs-rdf/

package/articles/surveys/structural-tension-methodology-survey.md

@@ -0,0 +1,154 @@
+# Survey of Structural Tension Methodology in Organizational Science and Computational Applications
+
+> Academic survey for the CoAiA.js project — From Fritz's creative process through Senge's learning organizations to computational structural tension in AI agent systems.
+
+## Abstract
+
+Structural tension—the creative gap between a desired outcome and current reality—has been a productive concept in organizational science since Robert Fritz introduced it in 1989. This survey traces the evolution of structural tension from its origins in Fritz's creative process methodology, through Peter Senge's integration into learning organization theory, to its contemporary application in computational systems and AI agent architectures. We examine three waves of structural tension research: (1) Fritz's foundational work on creative orientation and advancing vs. oscillating structures; (2) Senge's synthesis with systems thinking, mental models, and organizational learning; and (3) emerging computational implementations that encode structural tension as data structures driving autonomous agent behavior. The survey identifies key theoretical contributions, practical implementations, and open questions for the field, with particular attention to how structural tension provides a computational alternative to reward-based optimization in AI systems.
+
+## Introduction
+
+The concept of structural tension—tension between what is desired and what currently exists—appears across multiple intellectual traditions. In physics, potential energy stored in a stretched spring drives motion toward equilibrium. In psychology, cognitive dissonance theory describes the tension between conflicting beliefs. In organizational science, the gap between strategic vision and operational reality drives organizational change [1].
+
+Robert Fritz, working at the intersection of music composition, organizational development, and structural dynamics, formalized this concept as a methodology for creative work. Unlike prior treatments that viewed tension as a problem to resolve, Fritz positioned structural tension as a **creative force to harness**—the engine that drives purposeful advancement from current reality toward desired outcomes [2].
+
+This survey examines the trajectory of structural tension from Fritz's foundational work through organizational science applications to its newest frontier: computational implementation in AI agent systems.
+
+## Survey
+
+### Wave 1: Fritz's Foundational Framework (1989–2006)
+
+#### The Path of Least Resistance (1989)
+
+Fritz's seminal work introduced three key concepts:
+
+**1. Structural Causality.** Fritz argued that the underlying structure of any system—not the intentions, motivations, or effort of its participants—determines its behavior. A system structured for oscillation will oscillate regardless of how hard participants try to advance. A system structured for advancement will advance even through adversity [2].
+
+**2. Creative vs. Reactive Orientation.** Fritz distinguished two fundamental orientations:
+- *Creative orientation:* The desired outcome is the primary reference point. Action is driven by the vision of what one wants to create.
+- *Reactive/responsive orientation:* The problem is the primary reference point. Action is driven by the desire to eliminate what one doesn't want.
+
+Fritz demonstrated that reactive orientation produces oscillating structures (the "rocking chair" dynamic—moving away from problems but always returning), while creative orientation produces advancing structures (building upon each achievement) [3].
+
+**3. The Structural Tension Chart.** Fritz operationalized his theory as a practical tool: the structural tension chart, which holds two elements simultaneously:
+- A clearly articulated desired outcome (what you want to create)
+- An honest assessment of current reality (what currently exists)
+
+The gap between these elements generates structural tension, which resolves through the path of least resistance—ideally, through advancement toward the desired outcome [4].
+
+#### Creating (1991) and Corporate Tides (1996)
+
+Fritz extended the framework to artistic creation and organizational transformation:
+- *Creating* applied structural tension to the creative process in art, music, and writing, demonstrating that the same structural principles operate across domains.
+- *Corporate Tides* applied the framework to organizational change, showing how corporate structures that are designed for oscillation (cost-cutting → growth → cost-cutting) can be restructured for advancement [5].
+
+#### The Managerial Moment of Truth (2006)
+
+Co-authored with Bruce Bodaken (CEO of Blue Shield of California), this work introduced the MMOT cycle as the calibration mechanism for structural tension in organizational settings:
+1. Acknowledge the truth about current performance
+2. Analyze how it got to be that way
+3. Create an action plan
+4. Establish a feedback system
+
+The MMOT cycle was implemented at Blue Shield of California with documented improvements, providing the first large-scale organizational validation of structural tension methodology [6].
+
+### Wave 2: Senge's Learning Organization Integration (1990–2010)
+
+#### The Fifth Discipline (1990)
+
+Peter Senge, writing contemporaneously with Fritz, integrated structural tension into his learning organization framework. Senge's five disciplines—personal mastery, mental models, shared vision, team learning, and systems thinking—provide the organizational context within which structural tension operates [7].
+
+Senge explicitly credited Fritz's concept of creative tension (Senge's term for structural tension) as foundational to personal mastery—the discipline of clarifying personal vision and honestly assessing current reality. Senge argued that creative tension is the generative force that drives learning and growth in organizations [7][8].
+
+**Key Senge Contributions:**
+
+1. **Systems thinking context.** Senge situated structural tension within systems thinking, showing how organizational structures (feedback loops, delays, archetypes) determine whether creative tension resolves through advancement or oscillation.
+
+2. **Shared vision as collective structural tension.** Senge extended Fritz's individual creative process to organizational scale, arguing that shared vision creates collective structural tension that aligns individual efforts.
+
+3. **Mental models as reality distortion.** Senge identified mental models as the primary obstacle to honest current reality assessment—the critical foundation of structural tension. If current reality is assessed through distorted mental models, the resulting tension is misaligned [9].
+
+#### The Fifth Discipline Fieldbook (1994) and Systems Thinking Applications
+
+Practical applications of Senge's framework demonstrated structural tension in:
+- Corporate strategy (Gap Inc., Ford Motor Company)
+- Education (schools as learning organizations)
+- Healthcare (hospital system improvement)
+- Community development (sustainable change initiatives) [10]
+
+These applications validated structural tension across diverse organizational contexts while also revealing limitations: without the discipline of honest current reality assessment, structural tension becomes "creative tension theater"—the appearance of advancement without genuine progress.
+
+### Wave 3: Computational Structural Tension (2024–Present)
+
+#### Structural Tension as Data Structure
+
+The emerging wave treats structural tension not as a metaphorical framework but as a **computational construct**—a data structure with defined operations, measurable properties, and algorithmic implications.
+
+The key insight enabling this transition is that Fritz's structural tension chart can be formalized as a tuple: `STC = (D, R, A[], T, Δ)` where D is the desired outcome, R is current reality (append-only log), A[] is the action step array, T is computed tension, and Δ is the temporal delta history.
+
+This formalization enables:
+- **Tension computation:** Algorithms that measure the gap between D and R
+- **Oscillation detection:** Analysis of Δ history to identify advancing vs. oscillating patterns
+- **Telescoping:** Recursive decomposition where each action step becomes its own STC
+- **MMOT automation:** Systematic evaluation of agent output against Elements of Performance
+
+#### AI Agent Goal Management
+
+Traditional AI agent goal architectures (goal stacks, utility functions, BDI models) lack the dual-reference-point structure that prevents oscillation. Computational structural tension provides this structure:
+
+- **Goal stacks** only encode the desired state; there is no formal "current reality" that evolves.
+- **Utility functions** encode preferences over states but don't maintain the vision-reality duality.
+- **BDI models** maintain beliefs (roughly analogous to current reality) and desires (analogous to desired outcomes) but don't formalize the tension between them as a driving force.
+
+Structural tension charts fill this gap by making the tension itself—the measured gap between vision and reality—the primary driver of agent behavior.
+
+#### Implementation: CoAiA Framework
+
+The CoAiA (Creative Orientation AI Architecture) framework represents the most complete computational implementation of structural tension methodology, encoding:
+- Structural tension charts as JSONL-backed state machines
+- MMOT as automated self-evaluation cycles
+- Four Directions orchestration aligned with the Medicine Wheel framework
+- Elements of Performance as evaluation rubrics
+- Telescoping as recursive goal decomposition
+
+### Cross-Wave Themes
+
+Several themes persist across all three waves:
+
+1. **Honest current reality assessment is the critical capability.** Fritz, Senge, and computational implementations all identify reality distortion as the primary failure mode. If the agent (human or AI) cannot honestly assess current reality, structural tension misfires.
+
+2. **Structure determines behavior.** The arrangement of goals, reality assessments, and action plans—not the effort or capability of the agent—determines whether the system advances or oscillates.
+
+3. **Creative orientation outperforms problem-solving.** Across domains (personal, organizational, computational), systems oriented toward creating desired outcomes outperform systems oriented toward eliminating problems.
+
+4. **Self-evaluation requires a framework.** Left to their own devices, both humans and AI agents rationalize gaps rather than honestly acknowledging them. The MMOT cycle provides the structured framework that overcomes this tendency.
+
+## Implications for CoAiA.js
+
+This survey establishes CoAiA.js's theoretical lineage:
+
+1. **Fritz provides the foundational theory.** Structural tension charts, creative orientation, and advancing structures are direct Fritz implementations.
+2. **Senge provides the organizational context.** Systems thinking, shared vision, and mental models inform multi-agent coordination.
+3. **MMOT provides the calibration mechanism.** The four-step evaluation cycle ensures ongoing honest assessment.
+4. **Computational formalization enables automation.** By treating structural tension as a data structure rather than a metaphor, CoAiA.js enables AI agents to operate from creative orientation.
+
+## Conclusion
+
+Structural tension methodology has evolved from a personal creativity tool (Fritz, 1989) through an organizational learning framework (Senge, 1990) to an emerging computational paradigm for AI agent design (2024–present). Each wave has deepened the understanding of how the gap between vision and reality can serve as a creative force rather than a source of frustration. The computational wave—represented by implementations like CoAiA.js—promises to make structural tension methodology accessible to AI systems, enabling agents that advance toward creative goals rather than merely reacting to problems.
+
+## References
+
+1. Senge, P. (1990). *The Fifth Discipline: The Art & Practice of the Learning Organization*. Doubleday.
+2. Fritz, R. (1989). *The Path of Least Resistance*. Fawcett Columbine.
+3. Fritz, R. "The Creative Process." Robert Fritz Inc. https://www.robertfritz.com/wp/the-creative-process/
+4. Fritz, R. "Tension Seeks Resolution." Robert Fritz Inc. https://www.robertfritz.com/wp/principles/tension-seeks-resolution/
+5. Fritz, R. (1996). *Corporate Tides: The Inescapable Laws of Organizational Structure*. Berrett-Koehler.
+6. Fritz, R., & Bodaken, B. (2006). *The Managerial Moment of Truth*. Free Press.
+7. Readingraphics. "Book Summary: The Fifth Discipline." https://readingraphics.com/book-summary-the-fifth-discipline/
+8. Umbrex. "Senge Five Disciplines." https://umbrex.com/resources/frameworks/organization-frameworks/senge-five-disciplines-of-the-learning-organization/
+9. The Fifth Discipline. Wikipedia. https://en.wikipedia.org/wiki/The_Fifth_Discipline
+10. SEBoK. "The Fifth Discipline." https://sebokwiki.org/wiki/The_Fifth_Discipline
+11. KanbanZone. (2025). "Peter Senge's Fifth Discipline: Systems Thinking for Smarter Workflows." https://kanbanzone.com/2025/fifth-discipline-systems-thinking-for-smarter-workflows/
+12. Systems Thinking Alliance. "Why Learning Organizations are Key." https://systemsthinkingalliance.org/peter-senges-framework-for-a-learning-organization/
+13. Buteau, A. "Lessons from Peter Senge." https://www.antoinebuteau.com/lessons-from-peter-senge/
+14. The Systems Thinker. "New Insights on the Path of Least Resistance." https://thesystemsthinker.com/new-insights-on-the-path-of-least-resistance/