Open Multi-Agent Framework · v0.1
LATTICE — Structure without center. Intelligence without authority.
LATTICE is a domain-agnostic framework design 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.
Current status
Design complete — implementation pending
Version
v0.1 · research / experimentation
Reference domain
Social media publication system
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 · General architecture
The complete framework at a glance
This architecture 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.
03 · 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.
Domain
Pluggable deployment-specific agents, tools, capability profiles, and initial domain knowledge.
Agent intelligence
Agent execution, context assembly, memory, knowledge, tools, capability profiles, and structured reasoning.
Runtime & coordination
Goal/task execution, parent-driven routing, dependency handling, failure escalation, and parallel work.
Infrastructure
Message broker, registries, persistence adapters, and external-service boundaries.
Observability
Domain events and traces for task flows, interaction maps, message timelines, and distributed execution traces.
Core contracts
Transportable primitives, schemas, enums, and interfaces with no upward dependencies.
04 · Agent model
Hierarchical routing without a central scheduler
Main Manager Agent
Singleton entry point for external requests. It 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.
05 · End-to-end workflow
From request ingestion to completed goal
The workflow makes the runtime semantics concrete: 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.
06 · Agent 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
07 · Communication & state
Broker-mediated messages and 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, protecting parallel execution from uncontrolled writes.
08 · Memory & knowledge
A deliberate separation between experience and 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 is intended to happen through negotiation, preserving domain independence. After task completion, a reflection step decides what is valuable enough to promote from task experience into persistent knowledge.
09 · Observability & failure
Multi-agent execution should not become a black box
Observability
The design calls for structured events carrying execution identifiers and supports task-flow graphs, agent-interaction maps, message timelines, and distributed traces through OpenTelemetry-compatible visualization such as Jaeger or Zipkin.
Failure handling
Failures are recorded as experience, then handled or escalated through the parent routing chain. Retry policy belongs to the agent rather than a framework-wide hardcoded limit. Human-in-the-loop intervention is outside v0.1.
10 · Reference domain
Social media publication as an architecture test
The design uses a social-media publication system to demonstrate 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.
11 · Implementation roadmap
Seven milestones from contracts to reference system
The supplied design documents define a sequential implementation plan. This case study intentionally distinguishes that plan from completed implementation.
Core contracts and domain model
Infrastructure and registries
Agent execution and context
Routing and failure handling
Memory and knowledge
Observability
Reference-domain integration
Engineering takeaway
LATTICE's main engineering contribution at this stage is the architecture itself: explicit ownership, contracts, dependency rules, communication invariants, and a clear separation between reasoning, execution, memory, knowledge, infrastructure, and domain concerns. The next proof is implementation against those contracts.