Achilles — Agent Engine

A single module of autonomous agents on top of Knowledge Store. An employee sets up a personal agent — prompt, schedule, knowledge tools — and it works on its own, under the owner’s permissions. An analyst library and team agents are the next horizon.

Architecture

t0 Trigger

the owner initiates a run, or the schedule fires

Agent = the owner before KS · the full ACL, pre-filter on the KS side

t0 Prompt assembly · 3 layers

1 platformsafety + organization 2 agent promptset by the owner 3 engineeringidentity + tools

the platform can’t be overridden by the agent prompt

t1 Start gate

enabled ∧ ¬admin_paused ∧ budget ∧ model_id≠NULL → start

enabled · owner’s lock admin_paused · sticky lock, admin

t2 Agentic loop · the model drives

thinks ▸ calls a tool ▸ observes ↻ again

repeats as a stretch, not a one-off event

spins until an answer or until the iteration cap · agent_iteration_cap

core · 3 read-only KS primitives: search graph sql + the owner’s choice from the catalog

Knowledge Store · read-only the tools pull from knowledge — the agent doesn’t write to KS

Weekly budget a per-user token cap · spent as the loop runs, lives longer than a single run

t3 Stop

an answer is reached or the iteration cap is hit

t4 Journal record

Run journal

agent_runs.output · tokens_used

Not a workflow builder — the model combines tools by intent, not a graph of nodes before the agent prompt — the platform prompt: safety and organizational rules, shared with chat

API

POST · GET/api/v1/agents
GET/api/v1/agents/options
GET · PATCH · DELETE/api/v1/agents/{id}
POST/api/v1/agents/{id}/run
GET/api/v1/agents/{id}/runs
GET/api/v1/admin/agents
GET/api/v1/admin/agents/{id}
GET/api/v1/admin/agents/{id}/runs
PATCH/api/v1/admin/agents/{id}/pause
GET · PATCH/api/v1/admin/agent-limits

Run-journal changes reach open screens as push nudges over the platform live-updates stream — the owner sees own agents, admins see all; the endpoints above stay the single source the client refetches.

Workzone Design

Detailed design decisions for the module.

Agent runtime Tool-calling harness Identity and permissions Launch and lanes Budget and control Data model Stack and structure Tests

Beyond the horizon

Analyst library v2 External orchestration v2 Agent swarm v2 Team agents v2 Launch and spend v2

Wireframes Surfaces

The module has no frontend of its own: the employee and admin screens are rendered by surfaces as thin clients of the shared API — → Web App for the employee, → Admin Panel for the admin.