A storybook for automation: how I set agents up inside a team

Every day, my agents research, draft and build from a shared library of work I can use again. Skills describe how to do a job, tools carry out single steps, and I review what comes back and make the decisions. Each useful addition gives the agents something to draw on tomorrow.

A team without that library is up against competitors whose agents start with more of the job already understood. Their own team starts from zero each time, so it pays more to solve familiar problems and takes longer to ship. That isn't the team's fault: nobody has shown them how to turn individual pieces of work into something everyone can use.

Buying more subscriptions leaves that gap in place. What closes it is a team that can find an existing capability, understand its limits and try it before deciding what needs building.

A catalogue of small building blocks

The idea I keep coming back to is Storybook, a workshop for building UI components and pages in isolation. I want the same qualities for automation: each block is discoverable, documented and testable on its own, so another person can understand it without unpicking an entire workflow.

I keep instructions and execution apart. A skill describes how to approach a job, and Claude Code skills are one way to create, manage and share those instructions. A tool gives the agent a defined action it can take while following them.

My starting rule for a tool is one input, one output and one clear purpose. The input can hold several fields, but the block should do one job well enough to be useful in different workflows.

Every block needs:

• A name: a verb and a noun, such as send_email, so the action is explicit.
• A description: when to use it, as well as what it does.
• An input schema: required fields, types and validation rules.
• A handler: the business logic, kept behind that contract.
• A structured response: data on success and an error on failure, so the agent can respond without its loop breaking.
• Secrets from the environment: credentials load at runtime and never sit in the definition.

Zod gives you schema validation with static type inference. Here the handler calls an email adapter, deliver, once validation succeeds:

import { z } from "zod";
const input = z.object({ to: z.email(), subject: z.string(), body: z.string() });
export const send_email = {
  name: "send_email",
  description: "Send an email to a recipient. Use when the user asks to notify someone by email.",
  input,
  async handler(raw: unknown) {
    const parsed = input.safeParse(raw);
    if (!parsed.success) return { success: false, error: "INVALID_INPUT" };
    const key = process.env.EMAIL_API_KEY;
    if (!key) return { success: false, error: "MISSING_SECRET" };
    try {
      const receipt = await deliver(parsed.data, key);
      return { success: true, data: { messageId: receipt.id } };
    } catch {
      return { success: false, error: "DELIVERY_FAILED" };
    }
  },
};

The description matters because the model uses it to choose an action. A clear schema can reject malformed arguments, but it can't rescue a tool whose purpose overlaps vaguely with everything else.

Keep the registry in a file

I once sketched a whole product for this catalogue, but I've changed my mind about how much infrastructure a team needs. I've watched teams spend months designing a registry platform without shipping a single useful tool, so I now start with a plain mapping in a file.

That mapping connects a tool's name to its definition and handler. An entry such as send_email gives the caller its description and schema, while the execution path validates the input, runs the handler and returns the result. Adding a block means importing it and adding one entry.

I still want the storybook qualities, but they don't need a platform. Keep an example input and expected output with each block, write down its limits and give it an owner. Someone should be able to test it in isolation before it goes into an agent's work.

The sharing layer is a Model Context Protocol (MCP) server. It exposes tools with a name, description and inputSchema, and compliant clients discover them through tools/list and run them through tools/call. The server adapts the registry to that interface, while the handlers keep the business logic.

A block can also be used from a workflow built in n8n, with an adapter where needed. Keeping the contract separate from the caller lets a team reuse the same capability whether an agent or a workflow is calling it.

Four levels of working with automation

Most teams I meet think they're at level 2, but shared subscriptions can hide how little work is actually shared. I judge the level by what happens when another team needs a capability that already exists.

Level 1: grassroots chaos

People have seats, subscriptions and their own automations, but nobody knows what anyone else has built. Every project starts from zero because earlier work is hard to find or tied to one person's setup.

The barriers to leaving this stage are rarely technical:

• There's no mandate from the top, so it stays a side experiment.
• Nobody owns the architecture, so everyone does their own thing.
• Teams like their own tools and resist standardising.
• Nobody has measured any value yet, so the investment is hard to justify.

I start with one shared problem that touches several teams, because a request to standardise everything gives people little reason to take part.

Level 2: systematic integration

The team has a shared tool library, a registry, coordinated agents and metrics tied to results. Each agent gets the tools its job needs, while people can find and improve the same blocks underneath.

Work begins to compound, because a new workflow starts with capabilities that already exist. I look for actual reuse across workflows rather than counting how many entries the catalogue holds.

Level 3: process reinvention

At this level I ask what the process would look like if we designed it from first principles with agents available. That can change where work starts, what people review and which steps are needed at all, rather than speeding up the existing sequence.

I wouldn't jump from level 1 to level 3. Without reliable shared tools, a redesign leaves the team inventing the process and its foundations at the same time.

Level 4: autonomous operations

Level 4 means systems that watch outcomes, find improvements and adopt changes with little intervention. I still treat that as mostly theoretical, and human oversight stays part of how I work.

My attention goes to making the library dependable and the review decisions clear. A team can get a great deal done without making autonomous operations its destination.

A job discovery library in practice

For Contra, I built job discovery automation across LinkedIn and X for its freelancers. The earlier approach was scattered, with one-off scripts and manual workflows, so we grouped a shared library by domain:

• Platform tools: search jobs and read posts on LinkedIn and X.
• Classification tools: use LLMs to detect hiring signals and pull out job details.
• Pipeline tools: store leads and notify users.

Three specialised agents handled discovery, classification and delivery, each with only the tools it needed. The discovery agent never touched the pipeline tools, and the delivery agent never touched the platforms.

We started with five tools for one use case: LinkedIn job detection. The library reached twelve tools over eight weeks and never needed more, because each addition came from real usage rather than a speculative list.

We got three things wrong first:

• Versioning too early: I spent two weeks on tool versioning before the tools were stable. We fixed it by shipping version one and adding versioning only when a breaking change needed it.
• No retries: rate limits on outside services broke everything until exponential backoff went into every external call.
• A tool that tried to do everything: analyze_content handled posts, tweets, job listings and profile bios, and ended up full of conditional logic with poor results. Specific tools such as analyze_linkedin_post replaced it.

Those mistakes changed what goes into my first block on any job. I want a narrow purpose and predictable failure before I want a bigger library.

Production habits that support reuse

A shared block becomes a dependency for other people's work, so it has to fail in a way they can understand. These habits are small enough to apply from the first tool:

• Retry with backoff: space out retries for temporary external failures and cap the attempts.
• Return structured errors: catch failures at the tool boundary so they never break the agent loop.
• Version breaking changes: publish send_email_v2 alongside the old tool and mark the old one as deprecated in its description while callers move across.
• Test the agent's choice: check that a real request leads it to the right tool, as well as testing the handler.
• Log usage and failure: record which tools get called and which fail, so improvements follow evidence.
• Set permissions per tool: give each agent only the actions its role needs, and enforce that when the tool runs.

The logs tell me where to spend time, and the catalogue gives that work somewhere to land. Fixing a shared handler improves every workflow that relies on it, as long as its contract stays compatible.

Measure what changes for the business

A count of automations tells you what was built, but not whether it paid. I separate three kinds of value so the engineering connects to something the business recognises:

• Direct cost reduction: subscriptions removed, manual processes retired or a planned hire avoided because the work is handled.
• Revenue acceleration: the extra revenue from shipping a capability earlier or offering one you didn't have. Measure the delta, never all the revenue.
• Compounding value: build and maintenance work avoided because teams reuse a block that already exists.

I start with a spreadsheet, because the first job is agreeing what we're measuring. A dashboard won't fix an unclear baseline, and it won't turn spare hours into a saving on its own.

Watch the leading signs

Some numbers tell you early whether the library is working, long before a full year of results:

If reuse isn't climbing, it's usually a discovery problem (people don't know what exists) or a quality problem (the blocks don't solve real needs). Talking to the teams tells you which.

Keep a workflow log

I record each workflow's start date, deploy date, hours and reused and new components. For an illustrative email workflow, the log might read:

Hours should fall while reused components rise. A faster release only helps the business case, though, when I can say what that earlier release made possible.

Count reuse in hours

As a worked example, suppose three teams each need to send automated email. The block takes 80 hours to build, and a later CC and BCC change takes 16 hours:

These are example assumptions, not a client result, and a real comparison also needs each team's integration and support time. The gap keeps widening: a fourth team adds nothing to the shared column and another 80 hours to the other, and every later change is paid for once instead of three times.

Keep the baseline honest

Hours saved without an outcome are only capacity, so I record what happened to that capacity before claiming a return. Infrastructure, API usage and maintenance go into the same sum as the build, because they're part of what it costs.

I also measure the manual work that actually happens. If a slow job gets done twice a month, the baseline is two runs, not the ten someone wishes they had time for; extra runs the automation makes possible are a separate benefit.

Failures stay in the record too. Hiding the attempts that didn't work makes the whole calculation look suspect, while showing them earns trust for the ones that did.

I report quarterly with the trend: total investment, running costs, reuse, delivery time and business outcomes. The return tends to look modest in the first quarter, so leadership needs to see the line rather than a single snapshot.

Put the method to work in four weeks

I start with one use case that matters to the people who'll use it. A clear boundary gives us something concrete to test before anyone asks the rest of the organisation to adopt the approach.

• Week one: choose the use case and build three to five blocks with schemas, error handling and tests. Record the current process so the comparison has a baseline.
• Week two: create the registry file and put the first agent in front of real users. Use their requests and failures to improve the blocks and their descriptions.
• Week three: expose the tools through an MCP server and add monitoring. Check that clients can find and call the tools, and that failures show up in the logs.
• Week four: measure the first use case, write down the pattern and choose the next two or three. Look for work that can reuse what now exists.

Review runs through all of it. My agents research, draft and build, but I decide whether the result is good enough and what they take on next.

Teams that haven't seen this way of working tend to buy another tool and wait for it to help, so I teach it in a hands-on day on their own business. We work on a real job, so the team practises briefing the agents, reviewing what comes back and deciding which pieces are worth keeping for the next one.