Automation recipes

These recipes describe bounded sequences. Inspect the live REST schema or MCP tool inputs before implementation.

Daily workspace briefing

Use get_workspace_overview, list_tasks, and get_runtime_health. Summarize blocked and in-review work, pending attention, employee ownership, and runtime freshness. Keep this key read-only.

Structured task intake

1. Read list_agents and choose the intended owner.
2. Normalize the request into a title, summary, priority, and labels.
3. Call create_task once.
4. Call read_task on the returned identifier to confirm assignment and status.
5. Link the returned task identifier in the calling system.

Do not auto-retry an ambiguous failed write without checking whether the task already exists.

Review and reconcile existing work

1. Use list_tasks with a single status such as REVIEW or BLOCKED.
2. Call read_task before deciding; inspect comments, activity, approval summaries, and evidence-file metadata.
3. Use comment_task to record the reviewer, evidence needed, or next action.
4. Use update_task for content, assignment, priority, due date, or a status transition; use move_task when board ordering matters.
5. Re-read the task and compare status totals after the bounded batch.

A task comment or status change is not approval for a linked send, post, publish, spend, deploy, delete, or other guarded action. Do not mass-close a review queue merely to reduce its count, and do not assume two UI totals represent the same filters.

Synchronize approved company context

1. List current memory with list_memory.
2. Match the source document to an existing Yodu memory record.
3. Present a diff for human review.
4. After approval, call create_memory for a replacement version, or update_memory when editing an existing draft. Direct active edits are validated and re-applied, but a replacement draft keeps the review boundary explicit.
5. Call activate_memory with the reviewed draft identifier so the new version becomes active and reaches the runtime.
6. Record the source version outside Yodu for the next comparison.

Avoid replacing a carefully maintained company profile with raw source text. Creating or updating memory alone leaves a draft; activation is the explicit publish step.

Recruit and configure an employee

1. Call list_role_templates.
2. Use create_agent with a clear display name. New employees start with every workspace tool enabled; disable what the role does not need.
3. Use write_agent_config for role-specific operating guidance.
4. Set an available model and required skills.
5. Call provision_agent.
6. Confirm the employee with list_agents and runtime health.
7. Create one known test task before enabling more tools.

Configuration and provisioning require an owner or admin role.

Install a custom employee skill or helper script

1. Identify the employee with list_agents.
2. Review the file contents and choose a relative path beneath skills/ or scripts/.
3. Call write_agent_file as an owner or admin.
4. Provision the employee if needed, then run a bounded test task.
5. Inspect the resulting task, messages, and files before widening the employee's tool surface.

write_agent_file cannot replace runtime-owned root documents, write .env, use an absolute path, or traverse outside the employee workspace. It returns file metadata rather than echoing the file body.

Rotate a workspace or employee secret

1. Call list_secrets to inspect names, scope, provider, and update time without exposing values.
2. Decide whether the new value should be shared workspace-wide or override that name for one employee.
3. Call set_workspace_secret; include agentId only for the employee-scoped override.
4. Confirm the returned scope and version metadata.
5. Run a bounded employee test and revoke the old credential at its source when appropriate.

Secret values are write-only. A same-named employee secret takes precedence over the workspace value for that employee.

Register a private MCP server

Use add_custom_mcp_server only after reviewing the remote server's tool surface. It requires secrets:write because an optional authorization header is encrypted as a workspace secret. The tool returns server metadata, never the header value.

After registration, verify and grant the server through Yodu's employee tool-access workflow. Platform MCP registration does not automatically make every external action appropriate for every employee.