Agents, tools and skills

An agent configuration says which harness to use, what instructions to follow and which capabilities are available. Creating it does not start model work. A session uses that configuration for a particular conversation.

Give an agent one clear job

Save a reusable configuration in laufwerk/agents/researcher.ts. This example uses Docker; initialize with Docker or run prepare docker before its first turn. Authenticate Codex as described in provider setup.

import { createDockerExecution } from "@laufwerk/execution";
import { createCodex } from "@laufwerk/sdk/harness/codex";
import { tool } from "@laufwerk/sdk/ai";
import { z } from "zod";

const execution = createDockerExecution({ credentials: "codex-subscription" });
export const researcher = execution.agent({
  id: "researcher",
  harness: createCodex({ reasoningEffort: "low" }),
  instructions: "Answer from supplied evidence. Separate facts from uncertainty.",
  skills: [{
    name: "evidence-review",
    description: "Assess support for a claim.",
    content: "Identify the source for each claim. Say when evidence is missing.",
  }],
  tools: {
    readPolicy: tool({
      description: "Read the example company's current review policy.",
      inputSchema: z.object({}),
      execute: async () => ({ rule: "A person must accept a draft before publication." }),
    }),
  },
});

Declare zod in your consumer dependencies when importing it directly. This example's policy is deliberately static; replace it with an authorized integration when connecting a real system.

Instructions and capabilities are different

The custom readPolicy handler executes on the host. A real file-reading tool should constrain which files it can read; a publishing tool needs its own permissions. Instructions such as “never publish” do not remove a publishing capability.

When to add another agent

A researcher and writer can have different instructions and tools. Reuse one configuration across runs; start separate sessions for independent conversations. Add a reviewer when you can name the independent check it performs. Two agents repeating the same unsupported claim are still missing evidence.

Native MCP configuration is another integration route, with separate service authentication. The pinned adapter does not validate every MCP server option, and configuration forwarding alone does not prove tool availability. See the adapter and MCP reference before relying on it.

Reference: All agent and adapter settings

← Projects, workflows and runs · Next: Sessions and shared files →