agent-work-layer 如何在 TypeScript 中建立可靠的 AI 智能體工作交接

Making AI Agent Workflows More Reliable with Work Orders, Work Reports, and MCP

AI agents can generate code, research problems, and execute tasks. But what happens when one agent finishes its work and another needs to continue?

The challenge isn't just passing a message. It's preserving the task requirements, decisions, results, and remaining work in a form that another agent can understand and validate.

I've been building two npm packages to explore a more structured approach to this problem.

The problem with unstructured agent handoffs

Imagine a research agent that investigates a problem and passes its findings to a coding agent.

A simple message might contain the result, but it may leave important questions unanswered:

What exactly was the agent asked to do?
Which constraints did it need to follow?
What decisions were made?
What has been completed and validated?
What questions remain?
What should the next agent do?

As multi-agent workflows grow, these details become harder to manage with ad hoc messages alone.

Introducing agent-work-layer

agent-work-layer provides a structured foundation for representing and managing work in AI-agent workflows.

Source Code: https://github.com/probita-ai/agent-work-layer

The project is built around concepts such as Work Orders and Work Reports, with validation and lifecycle management.

The goal is to give developers a reusable way to define work, track its progress, and represent its results rather than reinventing these conventions for every agent system.

Install it with:

npm install agent-work-layer

Bringing MCP into the picture

The Model Context Protocol (MCP) provides a standard way for compatible AI applications to interact with tools and resources.

That's where my second package comes in:

agent-work-layer-mcp

It provides the MCP integration for the work layer, allowing supported work-management functionality to be accessed through MCP-compatible clients.

Install the MCP package with:

npm install agent-work-layer-mcp

The MCP integration is maintained separately from the core package, so developers can choose the appropriate package for their application.

What does this architecture make possible?

Consider a workflow with two agents:

1. The first agent receives a Work Order.

The task, requirements, constraints, and expected outcome are represented in a structured form.

2. The agent performs its work.

The workflow can track progress and apply the relevant lifecycle and validation rules.

3. The agent produces a Work Report.

The result can capture what was completed and provide information needed to evaluate the outcome.

4. Another agent continues the work.

The next agent can use the recorded context rather than relying entirely on a free-form conversation.

5. MCP provides the integration layer.

Where configured and supported, an MCP client can interact with the work layer through the available MCP tools.

The objective is to make work between agents easier to structure, inspect, and hand off.

An additional idea: controlled tool access

The project also explores an MCP gateway approach.

Rather than giving a worker unrestricted access to every available tool, a gateway can enforce the tool permissions associated with a work order and record tool usage. The implementation includes enforcement and observation modes.

This is particularly interesting for workflows where task boundaries, tool usage, and evidence of execution matter.

Explore the packages

Core package: https://www.npmjs.com/package/agent-work-layer
MCP integration: https://www.npmjs.com/package/agent-work-layer-mcp

Check the package documentation for the supported APIs, configuration, and compatibility requirements.

I'd love to hear from other developers

I'm interested in how people are approaching coordination and reliability in multi-agent systems.

How do you represent work passed between agents?
Do you use structured task and result schemas?
How do you restrict tool access for individual tasks?
What would make work handoffs more reliable in your own agent workflows?

I'm building these packages to explore a structured, reusable approach to agent work, and I'd appreciate feedback from developers working on similar problems.