Agentic AI Platform

What this is / is not

Problem

• Agent demos often collapse around retries, partial failures, approvals, and audit questions—not only model quality.
• Prompts and chains do not substitute for execution semantics: state, policy gates, tool contracts, and durable traces.
• Enterprise workflows need reconstructable runs, explicit policy evaluation, and operator tooling over stored artifacts.

Architecture

Operator-console and API clients call api-gateway only. The gateway forwards to orchestrator, which coordinates policy-engine, tool-runtime, knowledge-service, and model-runtime. Feedback-service, mukti-agent, and evaluation-engine consume completed work. PostgreSQL backs persistence in the default compose stack.

Stack: Python services (orchestrator, policy, tools, knowledge, model, feedback, Mukti, evaluation) · FastAPI api-gateway · Angular operator-console · PostgreSQL · Docker Compose local stack

Core capabilities

• Deterministic execution lifecycle

  Step-based plans with explicit state transitions, validation gates, and terminal outcomes owned by the orchestrator.

• Policy and approvals

  Policy-engine evaluates actions independently; high-risk operations can require recorded approval.

• Tool runtime

  Side effects flow through registered tools with typed contracts—not ad hoc HTTP from prompts.

• Bounded model runtime

  Models produce structured step outputs; they do not own execution state or transitions.

• Knowledge / evidence retrieval

  Retrieval steps ground answers with traceable corpus access before generation or action.

• Replay and replay diff

  Source executions replay as children; evaluation-engine computes server-side diff categories.

• Metrics and evaluation

  Platform rollups and per-execution evaluation exposed via gateway projections.

• Mukti insights

  Cross-execution advisory cards from stored feedback—advisory only, no runtime self-modification.

• Streaming operator console

  Live activity rail and SSE on active runs; grouped trace timeline and replay diff UX.

• Reference workflows

  Incident triage and cost attribution workflows seeded for local demo and investigation walkthroughs.

Operator console

Angular operator-console over api-gateway only: execution explorer, grouped trace timeline, replay diff, Mukti insights, policy simulation, and live activity. UI does not own execution semantics.

Why not LangChain / LangGraph as the execution engine?

• LangChain and LangGraph are useful for composing prompts, tools, and graphs in prototypes or bounded steps.
• This project keeps lifecycle, validation, replay, and policy semantics in the platform orchestrator—not in chain wiring.
• Execution state, policy evaluations, and tool calls are persisted and queryable; timelines are built from stored artifacts.
• Frameworks may be used at the edges inside a step where appropriate; they are not the system of record for execution.

Tradeoffs and limitations

• Local demo runs postgres, api-gateway, and operator-console; Python platform services are wired in-process inside the gateway image.
• Default model provider is fake for reproducible structured outputs without vendor API keys.
• Execution worker queue is in-process in local gateway configuration—not a separate broker service.
• Prometheus /metrics reflect the gateway process, not a full observability stack.
• Auth uses dev header fallback as a foundation—not enterprise OIDC.
• Not production HA or multi-region Kubernetes in this repository.

What this demonstrates

• AI platform architecture with separable policy, tools, models, and orchestration
• Deterministic control layer and explicit execution contracts
• Runtime systems thinking: retries, partial results, durable state
• Governance: policy evaluation and approval paths on the execution graph
• Observability: trace timeline, replay diff, metrics from stored artifacts
• Operational UX: operator-console over a thin gateway, not UI-owned semantics