Multi-agent systems: How PULSE provides a shared context foundation

In a multi-agent system, several AI agents work towards a shared objective. A coordinating agent can assign subtasks and combine results; a predefined workflow can also organise their work. The agents may have different tools, instructions and their own working contexts. This division is particularly useful when subtasks need extensive specialised knowledge or can be handled independently. LangChain therefore describes selecting what each agent sees as a central architecture decision.

In our machinery service example, technical preparation may require substantial equipment-specific documentation. Preparing the handoff instead involves service areas, team ownership and handoff requirements. Both checks can begin once the necessary case details are available. The customer response then draws on their results.

This division also adds handoffs and model calls. Anthropic describes both the value of parallel subtasks and the costs and coordination challenges of its own multi-agent system. A single agent with suitable tools may be entirely sufficient for a simple service request. Our example makes the requirements for collaboration visible; whether multiple agents make economic sense depends on the actual work involved.

The customer reports: “Our AX-20 machine is showing message E17. Please prepare a service visit.” The model and message are invented for this example. The customer has also supplied the site location; the serial number is missing.

Each agent now receives a defined task. Technical preparation checks the available details against the requirements in the relevant service documents. Handoff preparation establishes the responsible team and the conditions for passing the case on. The communication agent turns the findings into a clear response.

Technical preparation does not need every communication template. The communication agent, in turn, does not need every technical document in full. It needs the findings, their limitations and the rules for its own task. Shared context means using the same maintained foundation, with a selection tailored to each task.

PULSE connects knowledge with processes, roles and systems. Content can be maintained together, versioned and published. A handoff rule can therefore be managed where its business use is understandable. Connected agents can retrieve the published version as context. The content and relationships technically available depend on the configured connection. The public product description makes this distinction for external MCP access.

Explore how the published knowledge version is used at its linked locations. Maintain knowledge once. For people and AI agents.

For our application concept, the responsible people would link service documentation and handoff rules to the relevant activities. The agent environment would then need to retrieve these relationships and assemble the required sources. Whether each agent retrieves context directly or a shared component handles it is an architecture decision.

Three types of information come together. PULSE supplies maintained business context. The agent environment manages the task, work in progress and intermediate results. The service application supplies current case data and, where relevant, the confirmed status of a handoff or booking. This distinction needs to remain clear when deciding which information is authoritative.

MCP can standardise access to available information and tools. However, the protocol does not determine how an application selects and uses the context it receives. Deciding which source applies to a process step is also part of designing the solution.

Suppose technical preparation finds that the serial number is missing, preventing a reliable match to the documentation. Handoff preparation identifies the responsible team from the site location. Both results may be correct. A communication agent could still turn them into an excessive commitment: “Our service team will fix the fault.”

Assigning a team confirms neither the cause nor a service visit. The handoff should therefore contain more than a fluent summary. The following illustration records the actual state of our example:

The next task also needs the sources and versions used, together with the relevant case details. In our example, the next step is to ask the customer for the missing equipment identification.

The agent environment needs an agreed structure for these handoffs. Centrally maintained context helps locate the relevant requirements. The implementation must also preserve open questions when combining results. Technical permissions and any required human reviews need to be configured in the systems carrying out the work.

An appropriate draft would be: “Please send us your machine’s serial number so we can prepare the next steps. We have identified the responsible service team from your location. Once the equipment details are complete, we can clarify what happens next.” It describes progress without presenting preparation as completed execution.

The service team now changes its requirements. For the AX-20 range, a photo of the nameplate must also be available before a case is passed to dispatch. This rule is invented for our example.

This one change affects all three tasks. Technical preparation must recognise the photo as required information. Handoff preparation must treat a case without it as incomplete. Customer communication must specifically request the photo.

If these requirements are stored in three separate sets of agent instructions, all three need updating. In the shared context model, the business rule is maintained once and referenced where it is used. Each agent’s instructions still describe its procedure, for example: “Check completeness against the applicable requirements for the assigned activity.”

Publishing a new rule does not change context an agent has already loaded. The connection therefore needs to define when to retrieve it again and how to refresh cached information. A case already in progress also requires a decision: does the change apply to existing preparations or only to new cases? Being up to date and being applicable are different questions.

For an ongoing task, the implementation can record the source versions used and check before the handoff whether a relevant change needs reassessment. This makes a conflict explainable when one agent used the previous rule and another used the new one. Silently merging the two results would undermine the shared foundation.

A useful pilot case includes the model, serial number and location, but no nameplate photo. Under the previous example rule, equipment identification would be complete. Under the new rule, a required item is missing. This reveals whether the update has reached all participating agents.

Set three expected results for the pilot: technical preparation flags the missing photo; handoff preparation leaves the handoff pending; customer communication asks for the photo without claiming that the case has already been transferred. The source versions behind these results should also be traceable.

Then try a further check: deliberately give one agent an older source version. Does the step combining the results detect the conflict, or does it still produce an apparently unambiguous answer? This experiment tests collaboration and the connection. It is a proposed validation exercise, not a reported test result.

This gives PULSE a concrete role in multi-agent systems: business teams shape and maintain the shared working foundation. The agent environment uses the relevant context for each task and combines the results in a traceable way. With each additional agent, it becomes more important to establish whether its work follows the same applicable business rules.

To prepare such a use case, start with a process that draws on several areas of knowledge. Record which sources each step needs and which results must be passed on.

The guide explores the setup of a single agent activity. A multi-agent system adds the need for reliable handoffs between participants. Connect processes, skills and knowledge