Work / Research / LATTICE Framework
Open Multi-Agent Framework · v0.1
LATTICE — Structure without center. Intelligence without authority.
A domain-agnostic framework for cross-domain collaboration between specialized autonomous agents. Rather than treating agents as steps in a fixed LLM pipeline, the architecture gives them explicit identity, state, memory, knowledge, communication contracts, and responsibility for delegated work.
Status
Design complete — implementation pending
Version
v0.1 · research / experimentation
Reference domain
Social media publication system
Stack
Python · asyncio
01 — Problem framing
Why another agent framework?
LATTICE starts from an architectural problem: narrow agent pipelines work when execution can be predetermined, but become brittle as a system crosses domains, needs parallel work, or requires agents to remember, learn, ask for help, and collaborate without one component dictating every step.
The framework therefore models agents as autonomous entities rather than functions in a chain. Coordination is structured, but reasoning authority remains inside each agent.
02 — Design commitments
Multi-agent first
Single-agent operation is treated as a degenerate case rather than the primary system model.
Decentralized by design
There is no global state, central scheduler, or shared memory between agents. Coordination emerges through communication.
Asynchronous & parallel
Agents operate independently and tasks can execute concurrently wherever dependencies allow.
Research-grade v0.1
The current goal is architectural correctness and experimentation before production optimization.
03 — Architecture
The complete framework at a glance
This view connects the request and manager hierarchy to specialized workers, tools, framework infrastructure, private state, memory and knowledge, the per-agent reasoning loop, observability, and the framework's extension points.
FIG 01 — General Framework Architecture: the domain-agnostic LATTICE structure and its major boundaries · Open full resolution ↗
04 — Architecture
Strict boundaries, downward dependencies
The design documentation presents the framework at different levels of abstraction, including a six-layer conceptual architecture and a more detailed nine-layer component view. The invariant is the same: dependencies flow downward, Core imports nothing, infrastructure does not import agent modules, and agents never bypass the MessageBroker to communicate directly.
01
Domain
Pluggable deployment-specific agents, tools, capability profiles, and initial domain knowledge.
02
Agent intelligence
Agent execution, context assembly, memory, knowledge, tools, capability profiles, and structured reasoning.
03
Runtime & coordination
Goal/task execution, parent-driven routing, dependency handling, failure escalation, and parallel work.
04
Infrastructure
Message broker, registries, persistence adapters, and external-service boundaries.
05
Observability
Domain events and traces for task flows, interaction maps, message timelines, and distributed execution traces.
06
Core contracts
Transportable primitives, schemas, enums, and interfaces with no upward dependencies.
05 — Agent model
Hierarchical routing without a central scheduler
Main Manager Agent
Singleton entry point for external requests. Converts requests into goals, decomposes goals into high-level tasks, and routes work to sub-managers.
Manager Agents
Own a domain area, decompose tasks, delegate subtasks, collect results, and handle failures. Any agent that delegates becomes the router for that subtask.
Worker Agents
Execute domain-specific work using tools, assembled context, knowledge, memory, and LLM reasoning. A worker can become a router if it creates subtasks.
Delegation is capability-based. Agents expose skills, domains, and tool names through a CapabilityProfile; managers query the registry and use LLM reasoning to select an appropriate agent. Only manager-class agents may create new agents in v0.1.
06 — Workflow
From request ingestion to completed goal
Goal creation and decomposition, task routing, context construction, knowledge access, LLM decisions, tool invocation, local and shared-state updates, subtask delegation, result aggregation, and final delivery.
FIG 02 — System Workflow: a detailed execution trace across the framework primitives and agent tiers · Open full resolution ↗
07 — Execution loop
Message-driven, LLM-guided, asynchronous
Receive message
An agent dequeues a structured message from its private queue.
Build context
Relevant state, memory, knowledge, tool results, and dependency outputs are assembled into the reasoning payload.
LLM reasoning
The agent reasons over the structured payload.
Structured decision
The LLM returns a typed action instead of an uncontrolled free-form execution instruction.
Execute action
The framework executes one of the six defined action types.
Update & observe
Owned state is updated and a structured event is emitted to the observability pipeline.
Structured actions
08 — Communication & state
Broker-mediated messages, explicit ownership
Communication invariant
Every agent has a private queue and all inter-agent messages pass through the MessageBroker. v0.1 targets asyncio.Queue; the adapter boundary allows a later distributed transport such as Redis or RabbitMQ.
State ownership
AgentState is private to its agent. Shared TaskState lives in the task registry and can only be mutated by privileged owners through an async write lock.
09 — Memory & knowledge
Separating experience from domain understanding
Working memory
Task-scoped intermediate results and active reasoning state; cleared after task completion.
Episodic memory
Append-only history of outcomes, failures, and significant events.
Semantic memory
Accumulated factual knowledge at a coarser level than the structured knowledge graph.
Relationship memory
Records which agents were useful for which kinds of tasks, supporting better future routing.
Long-term memory
Persistent information that survives agent restarts and contributes to enduring agent identity.
Knowledge is modeled separately as each agent's graph-based domain ontology. Agents do not synchronize into one global knowledge store. Cross-agent semantic alignment happens through negotiation, preserving domain independence.
10 — Reference domain
Social media publication as an architecture test
A social-media publication system demonstrates how the domain-agnostic framework can be specialized: Research, Content, and Publishing sub-managers coordinate five specialized worker agents and domain tools for LinkedIn, Twitter, Instagram, and Facebook. The domain layer changes; the framework contracts underneath it do not.
FIG 03 — Social Media Publication Reference Architecture: one domain-specific configuration on the general LATTICE contracts · Open full resolution ↗
11 — Roadmap
Seven milestones from contracts to reference system
Core contracts and domain model
Infrastructure and registries
Agent execution and context
Routing and failure handling
Memory and knowledge
Observability
Reference-domain integration
12 — Decisions
Engineering decisions and what they cost
Model agents as autonomous entities rather than steps in a fixed LLM pipeline, so coordination stays structured while reasoning authority remains inside each agent.
Require every inter-agent message to pass through a MessageBroker rather than allowing direct agent-to-agent calls, keeping communication observable and transport-independent.
Separate private AgentState from a shared, write-controlled TaskState guarded by an async write lock, protecting parallel execution from uncontrolled writes.
Keep Memory (five distinct layers) and Knowledge (per-agent domain graphs) as separate concerns rather than one undifferentiated store.
Only manager-class agents may create new agents in v0.1, keeping delegation capability-based and queryable through a CapabilityProfile registry.
Treat observability and failure handling as first-class architecture concerns — structured events, task-flow graphs, and parent-routed escalation — not add-ons.
13 — Stack