| a15a859c6bb4939c… | Tenant overlays configure platform behavior per tenant and do not contain platform code so that customization is isolated from the core implementation. | active | contextual | yes | |
| 7bc4f34088ee074d… | Per-tenant overlays contain agent definitions, workflow configs, data connectors, and SQL templates so that each tenant can customize platform behavior through configuration assets. | active | contextual | yes | |
| a10844aa4c8959f6… | The platform supports multi-tenancy through client overlays in the `clients/` directory, including examples such as `clients/jnj/` and `clients/patrick/`, so that tenant-specific configuration is separated by client. | active | contextual | yes | |
| 8ebafac024c9dc73… | CI/CD uses GitHub Actions and changesets for versioning so that automation and release version management are handled by those tools. | active | contextual | yes | |
| b02a1690ff310676… | Package management uses uv for Python and pnpm for TypeScript so that dependency management is split by language ecosystem. | active | contextual | yes | |
| 591107c4c288ca8d… | Infrastructure uses Docker or Podman, Kubernetes, Helm, and Azure so that the platform can be containerized, orchestrated, packaged, and deployed in Azure environments. | active | contextual | yes | |
| 50e8012cc43d3cda… | Observability uses the full OpenTelemetry suite together with Langfuse and Prometheus so that tracing, monitoring, and telemetry are available across the platform. | active | contextual | yes | |
| 445c586b81aadb2c… | Authentication uses Azure AD, OAuth, and JWT with PyJWT and MSAL so that the platform supports enterprise identity and token-based auth flows. | active | contextual | yes | |
| 75962fd37e63c1c6… | The frontend tech stack uses Next.js 16, React 19, Vite, and TypeScript so that the user interface is built on a modern JavaScript and TypeScript toolchain. | active | contextual | yes | |
| f8a1f3a878cee27f… | The backend tech stack includes FastAPI, Temporal, PostgreSQL, Redis, and a LiteLLM proxy so that the platform backend supports APIs, orchestration, storage, caching, and model routing. | active | contextual | yes | |
| fbb90f7f2663672c… | The output gateway is schema-driven through pyrana-packets so that output processing follows defined packet schemas. | active | contextual | yes | |
| 4c9e55760d0225fe… | The output gateway processes results through the pipeline normalize, derive, validate, and persist so that outputs are transformed and stored in a staged sequence. | active | contextual | yes | |
| e0ba7442728d0748… | Agent objectives use `{variable}` template syntax hydrated from workflow execution context so that objective text can be parameterized with runtime values. | active | contextual | yes | |
| 839c1abdb36e894a… | Workflow configurations are stored alongside agent configs in `config/workflows/` so that workflow behavior is configured near related tenant agent definitions. | active | contextual | yes | |
| 7a282c21d7cf80e1… | Agent definitions are stored as YAML configuration files under `clients/<client>/backend/config/agents/` so that each client can define agents through tenant-specific configuration. | active | contextual | yes | |
| 61f9d72f902c26c4… | A typical platform request flows from API to PlannerDelegator to ExecutionPlan to GenericExecutor to `execute_action_agent` to PyranaHarness so that planning, execution, and harness runtime occur in sequence. | active | contextual | yes | |
| edf51d288c62442f… | BatchOrchestratorWorkflow runs batches of entities through a workflow so that the platform can process multiple entities under one orchestration pattern. | active | contextual | yes | |
| a9ac8001275bd0e1… | SubagentWorkflow runs spawned child agents through the `dispatch-subagent` tool so that delegated subagent work executes in a dedicated workflow. | active | contextual | yes | |
| 2dbda5632822c46e… | GenericExecutorWorkflow executes DAG-based plans and dispatches `execute_action_agent` for each node so that plan nodes are run through the action-agent activity. | active | contextual | yes | |
| 2360fc4a5cb93ff4… | PlannerDelegatorWorkflow is the top-level planner workflow that creates execution plans and delegates work to action agents so that planning and delegation are centralized at the top of the Temporal workflow hierarchy. | active | contextual | yes | |
| e5f000228d63447e… | The platform organizes tools into the categories discovery, data fetching, artifacts, context management, completion, delegation, hierarchy, HITL, lifecycle, and context engine so that tool capabilities are grouped by function. | active | contextual | yes | |
| 82c2d86146436a8d… | The tool decorator supports the flags `requires_context`, `is_base_tool`, `subagent_prohibited`, `approval_required`, and `bypass_size_guard` so that tool behavior can be configured with explicit runtime metadata. | active | contextual | yes | |
| 4f7e58c7c1fdc297… | Each discovered tool is wrapped in a DecoratedToolServer and executed in-process without an external MCP server so that tool invocation remains local to the runtime. | active | contextual | yes | |
| 78e1dbed1d20b09a… | Tools are discovered at startup through entry points, convention scanning, and a static manifest so that the runtime can assemble the available tool set automatically. | active | contextual | yes | |
| a63a4eeca6551171… | All agent tools are Python functions decorated with `@tool()` from `inproc_mcp/decorators.py` so that the platform standardizes tool declaration in code. | active | contextual | yes | |
| e8ea92c58c33bd70… | MessageBuilder in `message_builder.py` owns the full message lifecycle by accumulating conversation history and rendering the complete prompt each turn so that the LLM receives system text, history, and reminders together. | active | contextual | yes | |
| f07de789ca15c127… | Tools update AgentContext through the `update-plan` and `update-knowledge` mechanisms so that persisted belief state changes as the agent learns or revises its plan. | active | contextual | yes | |
| 2b1ccfd82936b04d… | AgentContext is stored in Redis and read on each turn so that the harness can reload persisted context during iterative execution. | active | contextual | yes | |
| 4ea26c74ee326b42… | AgentContext in `agent_context.py` stores persisted belief state including plan steps, accumulated knowledge, and artifact references so that the agent retains durable contextual state across turns. | active | contextual | yes | |
| 3116ac5f919c7c4a… | LoopAgentState is checkpointed for pause and resume behavior so that an interrupted agent run can continue from preserved execution state. | active | contextual | yes | |
| ac7685aee1e9a759… | LoopAgentState in `agent_state_v2.py` is a per-run state model that tracks turn control, counters, budget, HITL status, and observations so that the runtime can manage execution state for each run. | active | contextual | yes | |
| 59f58ef9932ba866… | The execution flow ends by building and persisting an `AgentOutputEnvelope` so that the final agent result is finalized and stored. | active | contextual | yes | |
| f7ee7045794fc2a5… | The native tool-calling loop repeats by having the LLM emit `tool_calls`, executing those tools, observing results, and iterating so that the agent can progress through tool-mediated reasoning cycles. | active | contextual | yes | |
| a6dbe9b3ea115849… | On turn 0, the harness creates an initial plan through an LLM so that the agent begins execution with a generated plan before entering the tool-calling loop. | active | contextual | yes | |
| 4b576575f52bd51f… | After the Temporal activity starts, the runtime calls `PyranaHarness.execute(config, workflow_input)` so that the harness can manage the agent run using the provided configuration and workflow input. | active | contextual | yes | |
| e4fd9886891678a3… | The execution flow starts with a Temporal Workflow entry point that invokes the `execute_action_agent` activity so that agent execution begins from Temporal orchestration. | active | contextual | yes | |
| 525d7ca704c03c4f… | The Pyrana harness implements native tool calling through LiteLLM in the orchestration layer so that action-agent execution can run an LLM-driven tool loop within the platform runtime. | active | contextual | yes | |
| 7da71402fe7f94ac… | MessageBuilder, defined in message_builder.py, owns the full message lifecycle by accumulating conversation history and rendering the complete prompt with system text, history, and reminders on each turn. | active | contextual | yes | |
| 477937df5410c6f2… | AgentContext, defined in agent_context.py, stores persisted belief state including plan steps, accumulated knowledge, and artifact references in Redis, and tools update it through update-plan and update-knowledge. | active | contextual | yes | |
| bfcebd8bddd27ad6… | LoopAgentState, defined in agent_state_v2.py, is a per-run state model that tracks turn control, counters, budget, HITL status, and observations, and it is checkpointed for pause and resume behavior. | active | contextual | yes | |
| 8270ee02a8a96378… | The final execution step builds and persists an AgentOutputEnvelope after the tool-calling loop completes. | active | contextual | yes | |
| 92553bdc9dbcd417… | The native tool-calling loop proceeds by having the LLM emit tool calls, executing those tools, observing results, and repeating the cycle until completion. | active | contextual | yes | |
| 61cc635c296fd44a… | On turn 0, the execution flow creates an initial plan through the LLM before entering the iterative tool-calling cycle. | active | contextual | yes | |
| 9eb790044f95b658… | After the Temporal entry point, the orchestration process calls PyranaHarness.execute with config and workflow_input to start harness execution. | active | contextual | yes | |
| c83fa2f8cc2690f8… | Agent execution begins when a Temporal Workflow entry point invokes the execute_action_agent activity as the first step in the execution flow. | active | contextual | yes | |
| 70710e2305dcd34f… | The core of the agent orchestration architecture is PyranaHarness, located at pyrana_services/orchestration/harness/pyrana_harness.py, and it implements native tool calling through LiteLLM. | active | contextual | yes | |
| 3082cdc9365c0036… | The TypeScript libraries are the main frontend deliverable, while custom frontends are built per client and consume the shared packages from Azure Artifacts. | active | contextual | yes | |
| 4a889230c5aafe32… | TypeScript libraries must be built in the order types, config, utils, ui and charts, auth, api, sdk, and admin so that dependency sequencing is preserved. | active | contextual | yes | |
| 5ce03413dc1141b8… | Within libs/ts, @pyrana/telemetry provides frontend observability capabilities. | active | contextual | yes | |
| c0faa4e639910cc3… | Within libs/ts, @pyrana/admin provides admin UI components for frontend administration features. | active | contextual | yes | |