Skip to content

OpenExchange

Introduction

AI Task Exchange

Xchange is a decentralized task exchange for Agents and AI systems.

In distributed task/problem solving, the main challenge is deciding how to assign tasks to different agents or AI systems. Agents that have a task to solve need a way to find the best available Agent to handle that task. This challenge is called the connection problem, and solving it is key for getting high performance in a distributed problem solver.

From the solver agent’s perspective, solve agents need to find other agents with a suitable task ready for execution. In our approach, both the Agents that have tasks and the Agents ready to execute tasks work at the same time to connect. They communicate in a way that’s similar to contract negotiations, agreeing on who will do what.

In Xchange, multiple autonomous agents or AI systems decide who should do what task, and possibly trade or reassign tasks to improve overall performance, efficiency, or fairness.

The connection problem has two parts:

  • Resource allocation: making sure effective resource allocation – the work is spread evenly across solving agents so no one is overloaded or sitting idle. This balance is important to get the maximum speedup when using multiple agents to solve one large problem.

  • Focus: choosing the right tasks to assign and picking the right agents to execute them, so the system’s effort goes where it matters most.

Xchange is a system of protocols by which multiple asynchronous, decentralized, and loosely coupled autonomous agents or AI systems running at distinct nodes cooperate and solve problems in a distributed manner.

Xchange also acts as a protocol for communication among the nodes in a distributed problem solver. It facilitates distributed control of cooperative task execution.

AI Task Exchange is a coordinated, often negotiation-driven process in which autonomous agents dynamically distribute, transfer, or trade tasks among themselves to achieve a more optimal alignment between task requirements and agent capabilities in a changing environment. It does both one-time allocation and continuous reallocation, where tasks may shift ownership as conditions evolve – such as when new tasks emerge, priorities change, resources fluctuate, or agents discover more efficient arrangements.

The Xchange system is decentralized, meaning control, AIs, data, and tasks are spread out across different nodes, with no single central control or storage.

It is loosely coupled, so each Agent or AI in the system works mostly on their own and only exchanges information on demand – needs information or results from others. In other words, they don’t constantly depend on each other to do their work.

Xchange underpins low-level communication protocols and a social mesh to support reliable and efficient communication between nodes to do cooperative work.

This approach can make problem solving faster, more reliable, easier to expand, better at handling uncertain or incomplete information, and well-suited for problems that are naturally distributed.

By treating task ownership as fluid and negotiable rather than fixed, Xchange enables resilient, scalable, and self-organizing behavior in multi-agent and distributed AI systems.

In this system, executing a task is treated like making a contract between two nodes.

For each task, agents can take one of two roles:

  • Manager - oversees the task, keeps track of progress, and processes the results when it’s done.
  • Contractor - actually carries out the task.

These are just temporary roles, and any agent can take on either role dynamically during the course of problem solving.

Contract Creation Process

A contract is created through local mutual selection, where both sides share information to decide if they’re a good match. Here’s how it works:

  • Managers announce tasks they need done.
  • Available contractors evaluate these announcements and submit bids for the tasks they can handle.
  • Managers review the bids and award the contract to the most suitable contractor.

This process can repeat. A contractor can split its task into smaller parts and give them to other agents, becoming a manager for those sub-tasks.

The result is a hierarchical control structure that’s common in task-sharing. Control stays distributed, because every node can both accept and assign tasks—there’s no single point of control or communication.

Why It’s Needed

In Multi-Agent Systems (MAS) or distributed AI networks, effective task handling is rarely a one-off allocation problem. Real-world environments require continuous adjustment:

  • No single agent has all the resources, skills, or complete knowledge to solve every task efficiently.
  • Tasks arrive unpredictably in complexity, timing and volume, and also vary widely urgency, and resource demand.
  • Environments are dynamic and unpredictable, meaning static task assignment quickly becomes suboptimal as conditions shift.
  • Agents differ in skills, specialization, speed, cost of operation, and availability, making some better suited for certain tasks than others at any given time.
  • Workload distribution becomes uneven over time - some agents may be overloaded while others remain idle, leading to inefficiency.
  • Failures or interruptions (hardware faults, network issues, software errors) may force tasks to be reassigned in real time to maintain continuity.
  • Opportunities for optimization often arise when agents can swap or trade tasks to reduce cost, time, energy consumption, or computation overhead.
  • Collaborative problem-solving sometimes requires tasks to be sequenced, decomposed, and passed between agents with complementary capabilities.

Task exchange addresses these challenges by enabling agents to coordinate dynamically, redistribute tasks as conditions change, and make locally optimal decisions that contribute to global system efficiency. This results in faster completion times, better resource utilization, increased robustness, and improved adaptability across the entire agent network.

Core Components of AI Task Exchange

Task Announcements

When an agent creates a task, it usually kick starts the contracting & negotiation phase by sending out a task announcement to other nodes. From that point, it acts as the manager for that task.

The announcement can be sent in different ways:

  • General broadcast / public - to all agents in the network.
  • Limited broadcast / Restricted - only to a selected group of agents.
  • Point-to-point / Private - directly to one specific agent.

A task announcement follows a task description protocol of choosing. Here are some of the mandatory fields expected to be expressed by the specification schema. The schemas can however be expanded to include fields that are essential for task communications and negotiations.

  • Eligibility Specification

  • is a list of requirements a agents must meet to be allowed to submit a bid for a task. It’s used to limit who can respond, and is applied when the manager has a preference to what types of agents are most suitable for the job.

  • Task Details

  • is a full detailed specification of the task. It helps solver agents compare it with other announced tasks.

  • Constraints

  • are specific limits or conditions that must be met when executing the task. They can include requirements like SLAs, time limits, resource usage caps, location restrictions, or quality standards. Constraints help ensure that tasks are carried out within acceptable boundaries.

  • Bid Specification

  • explains the format and type of information the manager wants in a bid. This ensures all bids are comparable and that agents only include relevant details in the response instead of sending full descriptions. This makes it easier for the manager to evaluate bids.

  • Expiration Time

  • is the deadline for receiving bids.

Task Announcement Processing

In a distributed task-sharing system, every task has a defined type. For each task type, nodes keep a ranked list of task announcements they have received that are still valid (not expired).

When a node receives a task announcement, it first checks the eligibility criteria to see if it can participate. This means verifying that the node meets all the stated requirements, such as having a specific capability or resource.

If the node is eligible, it then compares and ranks that task against other available tasks it could work on. This ranking helps the node decide which tasks to prioritize based on factors such as:

  • Task urgency or deadline
  • Expected benefit or payoff
  • Required resources versus available resources
  • Task complexity and risk
  • Relevance to the node’s current expertise or role

The ranking process is often task-specific, meaning the criteria for evaluation can vary depending on the task type. Similarly, many other operations in a distributed system like how bids are evaluated or how results are processed can also be task-type dependent.

To handle this, the system can define a task template for each task type. A task template specifies:

  • The structure and format of the task data
  • The rules for processing it
  • The ranking method
  • The way bids should be evaluated
  • Any special constraints or negotiation patterns

Using task templates provides consistency across the network, allows easy integration of new task types, and ensures each agent can process announcements for a given type in the same way. It also makes the system more extensible, new types of tasks can be added without rewriting the entire logic.

In a distributed task-sharing system, ranking of incoming task announcements happens continuously in parallel with the agent's current work. While the agent is busy processing its current task, it still evaluates and ranks new task announcements as they arrive - by themselves or by their sub agents.

Bidding

As the agent becomes available to take on new task, it decides to submit bids on the most promising tasks in its ranked list.

If only one type of task exists in the system, the decision is simple, pick the highest-ranked one. However, in environments with multiple task types, the selection becomes more strategic.

The strategy and decision to bid is task-specific. In some cases, the agent might prioritize the most recently received task to avoid bidding on tasks that are already taken. It might also factor in alignment, deadlines, urgency, or potential rewards with its own capabilities and priorities when choosing which task to bid on. In some cases, agents may sometimes wait for better opportunity window. Agents can also implement adaptive strategies, such as bidding aggressively when underutilized or selectively when resources are scarce.

When a agent does submit a bid, it includes a agent bid response directly relevant to the task. This matches the format requested in the task’s bid specification, ensuring bids are comparable.

Bid responses can also include conditional requirements which signal that the agent will need additional resources, data, or code to perform the task if awarded the contract. Such requirements are evaluated and negotiated during contracting.

Task templates are particularly useful here. They define the structure, data, and procedures for each task type. If a agent encounters a task type it doesn’t recognize, it can request the corresponding template - a compact way of obtaining all the necessary information to understand and process that task type without having to reconstruct its logic from scratch.

Sometimes a task announcement requests an immediate response bid. In this case, the node does not follow the normal process of ranking the task and waiting until it becomes idle before bidding. Instead, it responds right away.

Bid Processing

Managers keep track of contracts they have created in a task application queue until they are ready to award them. Alongside this, the manager maintains a ranked list of all bids received for the task.

  • Rolling-Award Model

  • When a new bid arrives, the manager compares and ranks it against existing bids. If one or more bids are judged satisfactory (based on criteria that depend on the specific task), the contract can be awarded immediately -without waiting for the official expiration time. This early awarding speeds up the overall negotiation process compared to systems that always wait until the deadline.

  • If the expiration time arrives and the contract still hasn’t been awarded, the manager can take several possible actions, depending on the task type and situation:

    • Award the contract to the most suitable bidder(s) available.
    • Reannounce the task if no bids have been received.
    • Delay and retry by waiting a short period before sending another task announcement if no acceptable bids were found.

  • Fixed-Deadline (Batch) Model

  • In this model, bids remain sealed until the expiration time. Once the deadline passes:

    • All bids are opened together.
    • The manager evaluates and ranks them in one batch.
    • The contract is then awarded to the most suitable bidder(s).

  • This method ensures that all interested parties have a fair chance to submit bids, and no one gains an advantage simply by bidding earlier. However, it can increase the time before a task starts.

  • Hybrid or Variant Models

  • Early-award threshold: Contracts can be awarded early if a bid meets a very high-quality threshold; otherwise, wait until the deadline.

  • Staged deadlines: Evaluation happens in rounds (e.g., early review at 50% of expiry, final at 100%).
  • Partial task allocation: For large or divisible tasks, parts can be awarded early while others are kept open for more bids.

  • Priority-based opening: High-priority tasks use rolling evaluation, low-priority ones use batch evaluation.

  • Immediate Response Models

  • The immediate response mechanism gives the manager faster feedback and helps decide what to do if no bids are received. Normally, if a task gets no bids, the manager would just reissue the announcement. With immediate response, the manager can take a more targeted action:

    • If all responses are BUSY - All agents are currently occupied. The manager can simply wait and reannounce the task later.
    • If all responses are INELIGIBLE - No agent meets the eligibility criteria. The manager can relax or adjust the eligibility requirements.
    • If all responses are LOW RANKING - Agents could do the task but consider it low priority. The manager might wait until the more interesting or urgent tasks are finished before reannouncing.

  • This mechanism helps avoid wasted time repeatedly broadcasting tasks when conditions make it unlikely that a bid will be received right away.

  • These approach differs from traditional static task allocation, where the manager would simply assign the task to the best available node at that moment without a dynamic bidding process.

  • Once a contract is awarded, the winning bidders are notified through an award message. This message includes:

  • The full task specification needed to start execution.

  • Any additional details or resources that the bidder requested during negotiation.

Contract Execution and Communication

Once a agent wins a contract, it follows a pre-defined flow that governs how it interacts with the task manager and any other involved nodes. This process includes a context that allows smooth communication and coordination.

Communication during execution typically involves:

  • Update messages - General updates or instructions exchanged between the manager and contractor while the task is in progress.
  • Reports - Sent by the contractor to inform the manager (and possibly other recipients) about progress. Reports can be:
  • Interim reports - Show partial progress or early results before the task is complete.
  • Final reports - Contain the complete results of the task and are the standard way of delivering outputs.
  • Result descriptions & evaluation - Included in reports to specify the outcomes of the work done and evaluation of the work to check if it meets expectations encoded in task details.
  • SLA compliance updates - Information on whether execution is meeting agreed service levels such as deadlines, quality standards, and performance targets.
  • Policy monitoring updates - Checks and confirmations that the work is following defined rules, ethical constraints, safety & security requirements, or other policy guidelines.

Interim reports can also be used for generator-style control, where a contractor produces results in stages, pauses, and waits for further instructions before continuing.

Managers may also terminate contracts when necessary. A termination message stops the task and cancels all related subcontracts.

Interim reports can also be used for milestone based control, where a contractor produces results in stages, pauses, and waits for further instructions before continuing.

Managers may also terminate contracts when necessary. A termination message stops the task and cancels all related subcontracts.

Progress-triggered reassignment - If interim reports show slow progress, the manager could reassign parts of the task to other nodes.

Direct Contracts

If a manager already knows exactly which agent is best suited for a task, it can issue a directed contract, skipping the full contract negotiation process and saving time.

In this approach, No public task announcement is made, No bidding process takes place. The manager sends a directed award message straight to the chosen node.

An acknowledgement confirms that the receiving node can accept the task, or provides a refusal with reasons (optional) if it cannot.

A refusal may happen if:

  • The agent does not meet the task’s eligibility requirements.
  • The agent does not have the task template needed to understand and process the task.
  • The agent decides, based on its own task-specific criteria, that it cannot or should not execute the task.

Request and Information Messages

Not all interactions require a full contract. If the manager or contractor only needs specific information (not actual task execution), a simpler request–response exchange can be used.

However, this exchange is governed by signaling rules and messaging restrictions to maintain efficiency, security, and trust within the network.

1. Message Types

  • Request message - A straightforward request for information.
  • Information message - The reply, containing the requested details. This can also be used for:
  • Routine communication between manager and contractor during contract execution.
  • Result-sharing – Agents proactively share partial results with others, even without a formal contract linking them.

2. Signaling Rules and Restrictions

  • Eligibility-based messaging - A agent can only send a request to another agent if:
  • The recipient meets the eligibility requirements stated for that information exchange.

  • The sender is authorized to communicate with that recipient (e.g., through role-based access, trust relationships, or policy rules).

  • Scope-limited messaging – Agents may only send unsolicited messages to:

  • Agents explicitly whitelisted in the system’s communication policy.

  • Agents currently participating in the same broader task or problem-solving context.

  • Directed signaling - In some implementations, requests must pass through designated communication channels or intermediaries, ensuring that messages are only exchanged between approved Agents pairs.

  • Traffic control - Policies may limit how frequently agents can send requests or unsolicited results to prevent overload.

3. When a Agent Receives a Request

  • If it meets the eligibility requirements and has the necessary information, it sends an information message.

  • If it lacks permission or does not meet the requirements, it either ignores the request or sends a refusal message, depending on the system’s rules.

  • When a Agent Receives an Information Message

  • If the message is tied to an active contract it is processing, it follows the specific contract’s handling procedures.

  • If there’s no active contract link, the agent applies a default action — this might be to store the data for later use, forward it to another agent, or discard it entirely, depending on defined policies.

  • Additional Insights

  • Access control layers ensure that sensitive information is only shared with authorized parties.

  • Signaling metadata can be included in messages so that recipients know the origin, intended scope, and handling requirements.
  • Restricting unsolicited messaging reduces spam-like network noise and ensures bandwidth is spent on relevant exchanges.

Dynamic Distribution of Information

In a distributed problem-solving network, dynamic distribution means that information such as data, procedures, or executable code can be shared between nodes on demand rather than being preloaded everywhere.

This is achieved through three main methods:

  • Direct request–response

  • A node sends a targeted request to another node asking for specific information. The reply contains exactly what was requested (for example, a software procedure, a dataset, or a configuration file).

  • Information as a task

  • A node broadcasts a task announcement where the task itself is simply to transfer certain information.
    Bids from other nodes indicate they have the requested information and are willing to send it.

  • Information as a bid requirement

  • When bidding on a task, a node can state that it needs specific information before it can execute the task. If its bid is accepted, the manager includes that information in the award message so work can begin.

Benefits of Dynamic Distribution

  • Better use of resources: An idle node that can’t execute a task because it’s missing some information can request and receive it dynamically, allowing it to start work without long delays.
  • No heavy preloading: Nodes don’t need to be preloaded with large amounts of data and code they may never use, reducing storage overhead.
  • Seamless onboarding: New nodes joining an existing network can quickly acquire the procedures and data needed to participate, without manual setup.
  • Scalable flexibility: The system can adjust to changing workloads and information needs without central reconfiguration.

Contrast with Traditional Task Assignment

In conventional systems, tasks are explicitly assigned to nodes, meaning new nodes must be manually linked into the network before they can take part. In a dynamic distribution system, new nodes can join, listen to broadcasts, acquire the needed procedures or data, and start working without special integration steps.