From b0c32e87518eca98e76efd21228117a1321706fe Mon Sep 17 00:00:00 2001 From: Sandipan Das Date: Sun, 20 Sep 2026 18:20:25 -0400 Subject: [PATCH 1/2] docs(readme): fix Pi GitHub link to earendil-works/pi --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 70aa6a6..a606681 100644 --- a/README.md +++ b/README.md @@ -28,7 +28,7 @@ gateway → app-ui, app-api → auth, pgsql, redis Argus is the system assembled around off-the-shelf foundations. It is not a from-scratch agent framework. The original work is the operational control loop *around* the agent, not the harness. -- **[Pi](https://github.com/earendil-works/pi-coding-agent)** (`@earendil-works/pi-coding-agent`) — +- **[Pi](https://github.com/earendil-works/pi)** (`@earendil-works/pi-coding-agent`) — the agent harness. It runs the per-turn tool-calling loop (model → tool call → observe result → repeat) and session lifecycle; Argus registers its 12 triage tools with Pi and drives the sessions. Configured under `.pi/agent/`. From 86e9a40a75de6cabead3741b7912ee94633ed549 Mon Sep 17 00:00:00 2001 From: Sandipan Das Date: Sun, 20 Sep 2026 18:21:17 -0400 Subject: [PATCH 2/2] docs: align tool count and table with 13 registered tools README.md and ARCHITECTURE.md claimed 12 tools but argusTools exports 13: the original 12 plus list_all_alerts. Add list_all_alerts and check_logs to the README table and update all '12' references to '13'. Also add list_all_alerts to the system prompt tool list and RCA instructions so the model knows about the registered tool. --- ARCHITECTURE.md | 8 ++++---- README.md | 4 +++- argus-server/agent/system-prompt.ts | 4 ++-- 3 files changed, 9 insertions(+), 7 deletions(-) diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md index 490c64b..dd99cd5 100644 --- a/ARCHITECTURE.md +++ b/ARCHITECTURE.md @@ -79,7 +79,7 @@ agent framework: - **[Pi](https://pi.dev/)** (`@earendil-works/pi-coding-agent`) — the agent harness. It owns the **inner loop**: within a single turn, *model → tool call → observe result → repeat → final answer*, plus session lifecycle and token streaming. Argus - registers its 12 domain tools with Pi and drives Pi sessions; it does not reimplement this + registers its 13 domain tools with Pi and drives Pi sessions; it does not reimplement this per-turn loop. - **[Ollama](https://ollama.com)** — serves the local LLM the agent reasons with (`OLLAMA_BASE_URL` / `OLLAMA_MODEL`). - **[Bun](https://bun.sh)** — runtime for the server and the demo services. @@ -201,12 +201,12 @@ re-investigating from scratch. The agent's judgment is informed by past state, n signals, and the prompt explicitly tells it to verify current evidence before assuming the same fix applies. -### 3.3 The toolbelt (12 tools) +### 3.3 The toolbelt (13 tools) The agent's only access to the world is its tools. It never writes raw SQL or invents metric values: -`get_alert` · `list_active_alerts` · `check_service_health` · `check_logs` · +`get_alert` · `list_active_alerts` · `list_all_alerts` · `check_service_health` · `check_logs` · `get_recent_deployments` · `search_runbooks` · `create_incident` · `update_incident` · `list_incidents` · `notify_channel` · `request_confirmation` · `execute_runbook_step` @@ -417,7 +417,7 @@ argus-server/ Bun server (TypeScript): agent, reconciler, REST API, scrap service-url.ts resolves demo-service base URLs (localhost vs compose DNS, SERVICE_DNS) metrics.ts Prometheus exposition for the agent's own model usage (GET /metrics) agent/ system prompt - tools/ the 12 agent tools (argus-tools.ts) + tools/ the 13 agent tools (argus-tools.ts) db/ schema.ts (tables + migrations), api.ts (all queries), types.ts (domain model) Dockerfile multi-stage server image: builds the UI, then serves it + API + /ws on :3000 argus-ui/ React + Vite display-only console (TypeScript, src/main.tsx, src/types.ts) diff --git a/README.md b/README.md index a606681..c1d02db 100644 --- a/README.md +++ b/README.md @@ -30,7 +30,7 @@ framework. The original work is the operational control loop *around* the agent, - **[Pi](https://github.com/earendil-works/pi)** (`@earendil-works/pi-coding-agent`) — the agent harness. It runs the per-turn tool-calling loop (model → tool call → observe result → - repeat) and session lifecycle; Argus registers its 12 triage tools with Pi and drives the + repeat) and session lifecycle; Argus registers its 13 triage tools with Pi and drives the sessions. Configured under `.pi/agent/`. - **[Ollama](https://ollama.ai)** — serves the LLM the agent reasons with (local or cloud). It stays on the host, never in Docker. @@ -208,7 +208,9 @@ These runbooks are curated, human-authored knowledge the agent consults. The mod |------|-------------| | `get_alert` | Get details of a specific alert | | `list_active_alerts` | List all currently firing alerts | +| `list_all_alerts` | List all alerts, including resolved ones, for RCA and trend context | | `check_service_health` | Scrape live metrics from a service | +| `check_logs` | Query infrastructure logs, metrics history, and vmalert status | | `create_incident` | Create an incident with triage findings | | `update_incident` | Update incident status or root cause | | `list_incidents` | List incidents by status | diff --git a/argus-server/agent/system-prompt.ts b/argus-server/agent/system-prompt.ts index ecdf9f9..d1aa8fa 100644 --- a/argus-server/agent/system-prompt.ts +++ b/argus-server/agent/system-prompt.ts @@ -42,7 +42,7 @@ AUTONOMOUS OPERATION: RESOLUTION & RCA: - When you are told an incident's alerts have resolved WITHOUT an approved remediation (it auto-healed or someone fixed it outside Argus), do two things together: 1. Ask the operator whether they know how it got resolved (a recent deploy, a manual restart, a config change, etc.). - 2. Independently research it: check_service_health on the affected service, get_recent_deployments, and check_logs for metric trends around the recovery time. + 2. Independently research it: check_service_health on the affected service, get_recent_deployments, check_logs, and list_all_alerts for the alert history around the recovery time. Then write a concise root-cause analysis that COMBINES the operator's answer with your own findings, and save it with update_incident (set the rca field and status to resolved). Do not propose remediation for an already-resolved incident. - When an incident resolves because YOUR approved remediation worked, you already know the cause and fix — just write the rca via update_incident, no need to ask the operator. @@ -53,7 +53,7 @@ If asked outside scope: "I'm Argus. I handle incident triage only." YOUR TOOLS ARE THE ONLY DATA SOURCE -You have these tools: get_alert, list_active_alerts, check_service_health, check_logs, create_incident, update_incident, list_incidents, search_runbooks, get_recent_deployments, notify_channel, request_confirmation, execute_runbook_step. +You have these tools: get_alert, list_active_alerts, list_all_alerts, check_service_health, check_logs, create_incident, update_incident, list_incidents, search_runbooks, get_recent_deployments, notify_channel, request_confirmation, execute_runbook_step. All incident and service data lives in your SQLite database. When investigating, you MUST call your tools. Never invent metric values or service statuses — always call check_service_health or list_active_alerts to get real data.