Agents

Engram ships three first-party agents on one shared machinery, plus a registry for your own. The design rule that makes them safe: agents are ordinary callers of the memory layer — same access algebra, same tools, same telemetry. No agent has a privileged path.

Shared machinery#

Every first-party agent is a step-capped, spend-metered tool loop over a virtual-filesystem view of memory: tree, search, grep, and read for reading; write, edit, mv, and metadata tools for writing (Gardener only). Every tool call embeds the caller's access context — an instruction smuggled into captured content can ask for anything it likes; the SQL fence returns nothing outside the caller's scopes.

The Gardener — the compiler#

Covered in Core concepts: the read-write agent that turns raw captures into structured, deduplicated, embedded memory. The rules that bear repeating: it is fenced to the capturing caller's scopes and the target folder's subtree, every write lands as draft, it can never set a classification above the caller's clearance, and contradictions with approved memory are flagged for review — never silently overwritten.

The recommendation agent#

“Starting task X — what already exists?” A read-only agentic loop (retrieve → review → refine) that can run multiple searches and reads before answering — it can chase a workflow's referenced prompt, check whether a decision was superseded, or compare two candidate workflows. Output is structured: ranked suggestions (prompts, workflows, agents, past decisions, lessons) each with a rationale and confidence, plus explicit gaps (“nothing found for Y”).

• Non-approved items may be suggested but are always labeled — reuse decisions belong to humans.
• Accept/dismiss feedback closes the loop into analytics: which memories actually get reused becomes reputation.
• Exposed as POST /v1/recommend, MCP recommend_for_task, and fired automatically when a PM webhook creates a task.

The task router — Human-AgentOS#

Given a task (created manually, via POST /v1/tasks, or by a Jira/GitHub/Linear webhook), the router decides who should do the work: a human, a registered agent, or a pair — with a rationale and required approvals. It weighs capability tags against the agent registry, each agent's reliability score (rolled up from its actual task-run success rate), cost, whether an approved workflow exists for this task shape, and sensitivity (touching confidential folders raises the human-oversight bar).

• Human route — assigned with the recommended workflow and prompts attached.
• Agent route — a task run executes; output that matters lands as a draft memory.
• Pair route — agent drafts, human reviews and approves.

Governance is reused, not reinvented: an agent-executed task's output goes through the same review queue as everything else, and “human oversight required” is a first-class field on the routing decision.

Your agents: the registry#

Register your own agents with:

• Name, description, and capability tags (what the router matches on).
• An optional linked agent memory node holding its prompt/config — versioned and approvable like any memory. A new prompt version is a draft until a manager approves it; agent governance falls out of the existing lifecycle with zero new machinery.
• An invocation endpoint: internal, MCP, or webhook.
• A cost profile, and a computed reliability score from its task-run history.

The learning loop#

Every successful task run auto-captures its workflow and outcome back through the Gardener as a draft — the reviewer sees which task produced it. The next similar task gets routed better and arrives with a proven workflow attached. Utilization, cost, and reliability per agent accrue from the same records. Every completed task makes the organization smarter — that's the whole point.