Harness AI follows a 14-phase incremental roadmap numbered 0 through 13. Each phase delivers a self-contained increment of capability — every new phase adds functionality while preserving all architectural invariants and acceptance criteria established by prior phases. The MVP spans Phases 0–5 fully, Phase 6 partially (harness base included; full CRUD UI excluded); Phases 7–13 extend the system into advanced automation, observability, and controlled cloud AI access.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/joseluis-dev/harness-ai/llms.txt
Use this file to discover all available pages before exploring further.
Phases at a Glance
| Phase | Name | MVP? | Key capabilities added |
|---|---|---|---|
| 0 | Base ejecutable local | ✅ MVP | Monorepo, Astro SSR, PostgreSQL, Redis, runtime Python, Docker Compose, migrations, health checks, executions table, audit_events table, RQ job queue, executions UI |
| 1 | Integración de identidad externa | ✅ MVP | mcp-identity-connector, actor resolution, fail-closed gate for sensitive writes |
| 2 | Model Gateway local con vLLM | ✅ MVP | Local AI execution, POST /v1/chat and POST /v1/embed endpoints, model.call audit, allow_cloud=false default policy |
| 3 | MCP SQL readonly | ✅ MVP | mcp-readonly-sql service, SQL view allowlist, SELECT-only agent, tool_registry seed row |
| 4 | Watcher documental e ingestión | ✅ MVP | File watcher, document checksum registry, text extraction, versioned document records |
| 5 | Embeddings y RAG básico | ✅ MVP | pgvector, local embedding model, chunking strategy, permission-filtered document retrieval, citation support |
| 6 | Administración de agentes/herramientas/políticas | ⚠️ Partial MVP | Harness base included; full CRUD UI for agents/tools/OAuth clients/scopes/policies excluded from strict MVP |
| 7 | Webhooks n8n | ❌ Not MVP | HMAC-signed webhooks, n8n as OAuth client, event allowlist, outbound webhook support |
| 8 | Telegram seguro (NUEVO) | ❌ Not MVP | Telegram bot routing through Harness Core, identity resolution via mcp-identity-connector, all messages audited, source_type=telegram |
| 9 | Aprobación humana | ❌ Not MVP | approval_requests table, 202 + approval_id response for DESTRUCTIVE/EXTERNAL operations, approval UI in admin panel |
| 10 | LangGraph para expedientes | ❌ Not MVP | expediente_review_graph workflow, multi-step document processing, conditional approval gates |
| 11 | Agentes especializados | ❌ Not MVP | Domain-specific institutional agents (contratación, expedientes, reportes, soporte TI, normativo) |
| 12 | Observabilidad avanzada | ❌ Not MVP | Structured metrics, distributed tracing (OpenTelemetry), cost dashboards, audit export |
| 13 | Proveedores externos de IA | ❌ Not MVP | OpenAI, Anthropic, Gemini under explicit allow_cloud=true policy; data_classification enforced; local fallback |
Phase Dependencies
The roadmap has several hard dependency edges that must be respected:- Phase 8 (Telegram seguro) requires both Phase 1 (identity — to map
telegram_user_id→ institutional user) and Phase 7 (n8n webhooks — to reuse the HMAC-signed webhook pattern). - Phase 9 (Human approval) gates all
DESTRUCTIVEandEXTERNAL_SIDE_EFFECToperations. Phases 10 and 11 both depend on Phase 9 being active. - Phase 10 (LangGraph) requires Phase 3 (SQL readonly), Phase 5 (RAG), and Phase 9 (human approval) to be complete.
- Phase 13 (External providers) is always the last phase; it extends the Model Gateway built in Phase 2 and relies on Phase 12 observability for cost enforcement.
Phase 6 is intentionally split: the harness base (tool registry APIs, auth-sdk, policy engine) is part of the MVP. The full CRUD UI for agents, tools, OAuth clients, scopes, and versioned policies may be delivered in a subsequent iteration. See
deployment/02-mvp-definition.md for the canonical MVP boundary.Recommended Implementation Order
The 30-step implementation order fromreferences/03-implementation-order.md groups work as follows:
Phase 0 — Steps 1–12
Create the monorepo, Docker Compose local stack, PostgreSQL, Redis, Astro app, runtime Python, base migrations,
executions table, audit_events table, job queue, fictitious execution smoke test, and audit registration.Phase 1 — Step 13
Implement the identity connector mock (
mcp-identity-connector) so all downstream phases can attribute actions to a real institutional actor.Each phase must fully satisfy its acceptance criteria before the next phase begins. A phase that passes 4 of 5 acceptance checks is not complete. The criteria are integral, not gradual — this mirrors the architectural maturity standard defined in
references/04-architectural-maturity.md.