sathya-mithra-k/planner-agentic-ai

Purpose and Entry Points

This is a small planner-oriented agentic AI system with a Python backend and static browser frontend. The backend API entry point is backend/api/main.py; the browser entry point is frontend/index.html. The README provides no operational detail beyond the project name.

API Boundary

backend/api/main.py exposes the application-facing interface between clients and the agent workflow. It is the likely request orchestration boundary: frontend or other consumers submit planning prompts, and the API invokes backend coordination before returning a result.

Multi-Agent Coordination

backend/Agents/coordinator.py is the central control-flow component. It should own the end-to-end agent loop, selecting or sequencing specialist agents and consolidating their outputs. Agent modules are grouped under backend/Agents/__init__.py, separating workflow roles from API concerns.

Planning Stage

backend/Agents/planner.py defines the planning specialist. Its role is to transform an incoming objective and available context into a structured plan, proposed steps, or task decomposition. It is invoked through the coordinator rather than directly by the frontend.

Reflection / Revision Stage

backend/Agents/reflection.py represents a review stage after planning. It likely evaluates plan quality, identifies gaps or inconsistencies, and supplies feedback for revision. Together with the planner, it forms a generate–critique control loop managed by backend/Agents/coordinator.py.

LLM Integration Boundary

backend/core/llm_engine.py encapsulates language-model invocation. Agent implementations should depend on this module rather than embedding provider calls, making model selection, prompting, and response handling a core infrastructure boundary. External LLM provider details are not present in the repository tree or README.

State and Memory

backend/core/memory.py provides memory/state management for agent execution. It is the likely boundary for retaining conversation context, intermediate plans, reflection feedback, or prior results across workflow steps. The coordinator and agents should use it to avoid coupling state persistence to API handlers.

Client Surface and Runtime

The frontend is a lightweight static UI composed of frontend/index.html and frontend/styles.css; no frontend application framework is evident. The backend is Python, with dependencies declared in requirements.txt. The primary flow is: browser/client → backend/api/main.py → coordinator → planner/reflection agents → LLM engine and memory → consolidated API response.