Agents

Agents are bounded runtime participants#

Matruno includes internal agents for moderation/routing, document processing, document drafting, extraction, email, communication, matter/participant data updates, notes, todo items, follow-up review, chat, integration testing, and voice paths. These live under backend/app/agents and are called by API routes, services, or Temporal activities.

The implemented crm agent type updates matter details, participant records, and workflow checkpoints. It is not a customer-relationship product.

An agent is not a separate control plane. It should operate inside the matter/workflow/task model and write useful records back to execution history. Agents are Legal AI assistants inside a governed matter workflow. They are not autonomous lawyers and they do not provide attorney legal advice.

Logs are not model reasoning#

The database includes AgentExecutionLog, AgentEvent, ModeratorAgentLog, AssistantConversation, AssistantMessage, and AgentJob models. These support execution history, outputs, timing, tool calls, and debugging. Do not describe them as hidden chain-of-thought or "every step of reasoning."

Authority comes from workflow design#

High-impact agent actions should be bounded by workflow steps, matter tasks, human legal-review tasks, approval checkpoints, template bindings, and external tool configuration. A workflow may use an agent to draft, classify, extract, summarize, or enrich, but the workflow should make attorney review and completion visible.

Never invent facts, authorities, citations, case law, statutes, evidence, or party positions. If a source document or matter record does not support a statement, the agent path should say so.

Provider configuration#

Agent runtime depends on configured provider credentials such as OPENAI_API_KEY, ANTHROPIC_API_KEY, or the multi-key variants used by the Docker stack. Missing provider keys can make agent, extraction, or drafting flows fail or fall back depending on the route and service.