Goals, rules and memory

Agents and MCPSDKMCPDashboardagentsgoalsrulesknowledge_domainschedulesexecute_as

An agent automation carries goals that drive it, rules that constrain it and a knowledge domain it accumulates into over time.

The situation

A health monitor should watch for failures, capture diagnostics and alert people. It must never restart a failed workflow on its own. And it should get better at its job as it sees more incidents.

The recipe

agents: [{
  name: 'health-monitor',
  description: 'Captures diagnostics on failures and alerts before issues cascade.',
  goals: 'Detect failures early, capture diagnostics, and alert before cascading issues.',
  rules: 'Never auto-restart failed workflows. Always capture state and escalate to a person.',
  knowledge_domain: 'system-health',
  subscriptions: [
    { topic: 'workflow.failed', reaction_type: 'durable', workflow_type: 'captureDiagnostics' },
    { topic: 'app.*.*.error', reaction_type: 'durable', workflow_type: 'captureDiagnostics' },
  ],
  schedules: [{ cron: '0 * * * *', workflow_type: 'healthSweep' }],
}],

Part	What it does
Goals	The motivation that informs whether and how to act
Rules	Guardrails the agent keeps even when its goals suggest otherwise
Knowledge domain	Shared memory: one agent typically owns and writes it, others read it
Subscriptions and schedules	When X happens, or at this time, run Y as Z

The same fields ride create_agent and update_agent over MCP.

The guarantee

An agent runs as its configured identity: a subscription’s execute_as wins over the agent’s, and with neither set the workflow runs as lt-system. Configuring an agent requires builder access and the right to act as that identity. Pausing an agent stops its subscriptions and schedules and keeps its knowledge and history. See Agents and events.

Agents and MCP