Public architecture and evidence case study for a private distributed agentic platform that I build and operate across a small local compute fleet.
Repository boundary: this repository contains sanitized screenshots, architecture documentation, a time-stamped metrics snapshot, and links to generalized open-source components. The Talos application source, deployment configuration, private datasets, credentials, and security telemetry are not included.
Talos coordinates local language models, specialized agents, shared memory, business workflows, observability, and voice/chat control. The public material is intended to show system design and operating discipline without presenting the private platform as an open-source implementation.
The quantitative claims below come from a read-only fleet snapshot captured on 2026-06-20.
| Measured area | Snapshot value | Public evidence |
|---|---|---|
| Fleet topology | 4-node fleet | Role inventory in the snapshot; hostnames omitted |
| Managed workloads | 54 active agent-services | Per-node service counts in the snapshot |
| Local model gateway | 54 local language models | Per-GPU-node gateway counts in the snapshot |
| Vector memory | 648,631 vector points across 12 collections | Per-collection counts and total in the snapshot |
These are historical snapshot values, not a promise about the fleet's current state. The collection commands require access to the private network. External reviewers can inspect the published inputs and run the repository validator, but cannot independently query the live fleet from this repository alone.
The public evidence is deliberately separated into four layers:
metrics/snapshot-2026-06-20.jsonis the machine-readable source of truth for the four measured claims.metrics/snapshot-2026-06-20.mdrecords the read-only collection methods and sanitized outputs.assets/contains sanitized dashboard views illustrating the platform and its control surfaces.scripts/validate_public_evidence.pychecks arithmetic, README consistency, referenced files, and PNG signatures in CI.
The validator proves that the public case study is internally consistent. It does not attest to current private-fleet state.
The control surface provides a consolidated view of nodes, agents, pipelines, memory, models, and operational metrics, with voice and chat entry points.
Selected operational panels:
Screenshots are illustrative and may have been captured at different times. The dated metrics snapshot, not screenshot text, is the quantitative record for this case study.
| Area | Implemented scope | Boundary |
|---|---|---|
| Commerce and marketing | Store, catalog, supplier, payment, content, and ML-assisted workflow integrations | Private implementation |
| Sales | Prospecting and qualification workflows; negotiation and closing components | End-to-end e-signature validation remains in progress |
| Trading research | Strategy research, forecasting, and simulated decision environments | Paper/testnet scope; no live-performance claim |
| Creative workflows | Long-form, social, image, video, and scheduled publishing pipelines | Private implementation |
| Voice and multimodal control | Streaming speech, chat, routing, vision, and document processing | Sanitized UI evidence only |
| Builder pipelines | Audit, build, and architecture stages with execution checks | Generalized components are released separately where practical |
Talos is organized into five cooperating planes:
- Control plane: command center, request classification, routing, lifecycle, dashboard, and voice/chat control.
- Knowledge plane: knowledge wiki, episodic memory, shared strategic state, retention, research, embeddings, and reusable skills.
- Execution plane: commerce, sales, trading-research, creative, and builder workloads.
- Cognitive layer: forecasting, simulated decision support, governance, evaluation, and learning loops; longer-horizon planning remains in development.
- Reliability plane: metrics, logs, alerts, incident handling, runbooks, and bounded remediation.
An MQTT event bus and a local-model gateway connect these planes across the fleet.
The editable source for the diagram is
architecture.mermaid.
Python, async service design, local LLM operations with llama.cpp/GGUF, VRAM-aware routing and hot-swap, multi-agent orchestration, graph-RAG and vector search, MQTT, streaming STT/TTS, Prometheus-compatible telemetry, reverse-proxy ingress, systemd, and CI with Ruff, pytest, and pre-commit.
Engineering principles:
- Prefer execution-verified generation to single-shot output.
- Use independent checks for structure, semantics, and side effects.
- Separate measured evidence from architectural description.
- Record limitations and work-in-progress states explicitly.
- Keep private operational and security data out of public artifacts.
Selected infrastructure is extracted and maintained independently:
- agent-resilience — circuit breaker, Redis-backed DLQ, and offline MQTT buffer.
- async-api-client — resilient async REST client with rate limiting, retries, and pagination.
- multi-agent-orchestrator — capability-based task-routing template.
Those repositories have their own licenses and validation. Their publication does not imply that the private Talos platform is open source.
No third-party dependency is required:
python scripts/validate_public_evidence.pyThe same command runs in GitHub Actions. A successful result verifies the snapshot totals, README tokens, evidence paths, and image file signatures.
- The public repository cannot reproduce live fleet probes without private-network access.
- Metrics are tied to the stated snapshot date and may change afterward.
- Screenshots demonstrate interfaces, not service-level objectives or security assurance.
- Private code and infrastructure have not been independently audited through this repository.
Original documentation, diagrams, and structured snapshot data in this repository are available under CC BY 4.0. This does not license the private Talos implementation or third-party names and marks visible in the case study.