Federated Agentic Systems

Autonomous agents for federated science

Academy is middleware for building and deploying stateful agents across distributed systems and federated research infrastructure. An agent is a Python object that holds state, exposes actions other agents can call remotely, and runs its own control loops. An LLM is one thing you can put inside an agent; Academy does not require one.

Get started View on GitHub

pip install academy-py

MIT license Python 3.10+ v0.5.0 release history

          A first Academy program
        
import asyncio
from concurrent.futures import ThreadPoolExecutor

from academy.agent import Agent, action
from academy.exchange import LocalExchangeFactory
from academy.manager import Manager


class ExampleAgent(Agent):
    @action
    async def square(self, value: float) -> float:
        return value * value


async def main() -> None:
    async with await Manager.from_exchange_factory(
        factory=LocalExchangeFactory(),
        executors=ThreadPoolExecutor(),
    ) as manager:
        handle = await manager.launch(ExampleAgent())
        assert await handle.square(2) == 4


asyncio.run(main())

The problem

Agentic frameworks are built for the cloud, not for research infrastructure

Existing agentic frameworks take a relatively narrow view of agents, apply a centralized model, and target conversational, cloud-native applications (e.g., LLM-based AI chatbots). In contrast, scientific applications require myriad agents be deployed and managed across diverse cyberinfrastructure. Empowering Scientific Workflows with Federated Agents, IPDPS 2026

Scientific work spans HPC systems, instruments, and institutions, each with its own queue, network policy and identity provider. Academy is the execution and coordination layer for that setting.

Academy is not a replacement for an LLM harness. It places agents and connects them; what runs inside an agent is up to the application. An agent that polls an instrument or drives a simulation needs no LLM.

The same Academy agent, deployed into four kinds of place that Academy does not own. This is design intent, not a deployment record. Each place is drawn as a dashed boundary — someone else's facility, instrument or trust domain — and inside each one sits an identical solid box: the Academy agent. The four places are an instrument, for low-latency control; a data store, for throughput; an HPC facility, for large-scale computation; and the cloud, for cross-site coordination. Five instrument kinds orbit the instrument, each joined to it by a tether that forms and fades: a beamline, a telescope, a sequencer, an imaging station and a detector array. They stand for the capabilities that one instrument slot can take, and there is nothing special about five of them. Instrument types are named as categories only; no specific integration, and no named facility, is claimed. All four agent boxes are the same component at the same size; only what fills them differs. Three run as micro-services and are deterministic. The one in the cloud is LLM-driven, and it is the only one of the four that reasons. Nothing reasons at the centre — the element in the middle is the exchange, which holds one mailbox per agent and only carries messages. Each mailbox is drawn as a curbside mailbox with a flag, and beneath it a tray of four marks. Both carry state rather than decoration: the flag is raised whenever at least one message is waiting in that mailbox, and one mark in the tray lights for each message waiting, so a mailbox holding three of the four it has room for shows three lit marks and one empty. Academy's mailboxes are persistent, so a message sent to an agent that is not there to take it waits in that agent's mailbox until it returns. Messages travel as letters between the agent boxes, crossing the dashed boundaries on the way out and again on the way in, and every hop is routed through the exchange: each letter is posted into the receiving agent's mailbox, waits there, and is then collected. The cycle repeats without stopping. Three messages arrive at the cloud agent's mailbox in turn — from the instrument, then the data store, then the HPC facility — and they queue there, the count rising to three, because the cloud agent is the one that reasons and is busy reasoning while they arrive. When it finishes it collects all three as a batch, and then sends work back out to the HPC facility, the data store and the instrument in turn; each of those three collects its own message, and the exchange is briefly quiet before the cycle begins again. The four placements, and the single reasoning agent among three micro-services, follow the project's experiences paper, Patterns and Experiences from Deploying Agents in Scientific Applications.

Define an agent

An agent is a class. @action methods can be invoked remotely by users or by peer agents; @loop methods run the agent's autonomous control loops until shutdown.

State lives on the instance and persists across invocations, so an agent can hold a model, a queue, or a live connection to an instrument rather than rebuilding it per call.

              Defining an agent
            
import asyncio
from academy.agent import Agent, action, loop


class SensorMonitorAgent(Agent):
    def __init__(self) -> None:
        super().__init__()
        self.last_reading: float | None = None
        self.process_threshold: float = 1.0

    @action
    async def get_last_reading(self) -> float | None:
        return self.last_reading

    @loop
    async def monitor(self, shutdown: asyncio.Event) -> None:
        # read_sensor_data and process_reading are yours to supply.
        while not shutdown.is_set():
            value = await read_sensor_data()
            self.last_reading = value
            if value >= self.process_threshold:
                await process_reading(value)
            await asyncio.sleep(1)

Let agents call each other

Agents hold handles to other agents and invoke their actions directly. Pass a handle in at construction and a coordinator can delegate work without knowing where the other agents are running.

Communication is asynchronous throughout: handles send messages to a mailbox managed by an exchange.

              Agent-to-agent calls
            
from __future__ import annotations

from academy.agent import Agent, action
from academy.handle import Handle


class Lowerer(Agent):
    @action
    async def lower(self, text: str) -> str:
        return text.lower()


class Coordinator(Agent):
    def __init__(self, lowerer: Handle[Lowerer]) -> None:
        super().__init__()
        self.lowerer = lowerer

    @action
    async def process(self, text: str) -> str:
        return await self.lowerer.lower(text)

Run it anywhere

Swap the exchange and the executor; the agent code does not change. A thread pool and a local exchange for development; a process pool and Redis across nodes; a Globus-backed cloud exchange across institutions.

Each exchange has its own prerequisites, so check what you need to provide before picking one.

              Distributing across nodes
            
from concurrent.futures import ProcessPoolExecutor

from academy.exchange import RedisExchangeFactory
from academy.manager import Manager


async def main() -> None:
    async with await Manager.from_exchange_factory(
        factory=RedisExchangeFactory('<REDIS HOST>', port=6379),
        executors=ProcessPoolExecutor(max_workers=4),
    ) as manager:
        ...

Run these locally →

Architecture

How Academy fits together

Two planes: the exchange moves messages between agents, and the executor decides where an agent actually runs. Keeping them separate is what lets the same agent code work on a laptop and across federated research infrastructure, and it is why mailboxes persist — agents behind a batch queue spend much of their life offline.

Academy's architecture in three bands. Across the top, the
Exchange forms a data plane holding one mailbox per participant,
with arrows running both ways between each mailbox and its
owner. In the middle, a User holds two Handles that point at
Agents; each Agent contains Actions, a Control loop, Handles to
other agents, and State. Along the bottom, Executors form a
control plane that the User and both Agents connect down into. — Agents expose actions and run control loops over persistent state, and communicate via distributed mailboxes on Academy's exchange.

If you already use Parsl or LangGraph

LangGraph, PydanticAI, LangChain: Inside the Agent box. They build the reasoning loop within a single agent. Academy does not constrain what that loop is, or whether there is one.
Parsl, Globus Compute: The executor row. The manager drives execution through any concurrent.futures executor, so these are what place an agent on a compute node.
Workflow systems: They replace the whole picture with a task graph submitted from one place. Academy's agents are long-lived and hold state between calls, so they suit feedback loops that never resolve into a static graph.

Read how this is instrumented for observability →

The model

What can be an agent?

An Academy agent is a primitive entity that has internal state, performs actions, and communicates with other agents. Stateful actors are one kind of agent, not a separate concept — that one building block covers a wide range of implementations.

Stateful actors

Manage their own data and respond to requests in a distributed system.

LLM agents

Integrate LLM-based reasoning and tool calling.

Embodied agents

The "brain" controlling a robot or simulated entity, where actions become motor commands or environment manipulations.

Computational units

Encapsulate a specific task — running a simulation, processing data, or training a model.

Orchestrators

Coordinate the activities of other agents, distributing tasks and monitoring progress.

Data interfaces

Interact with databases, file systems, or sensors behind a consistent interface.

What Academy provides

Stateful agents: Agents keep their data between invocations, so a long-running process carries context from one step to the next instead of rebuilding it.
Agent autonomy: Control loops run inside the agent, so it can react to events and start work without the submitting process being involved.
Flexible deployment: Academy handles launching agents, addressing them, and routing messages between them, so one application can span a laptop, a cluster behind a batch scheduler, and a machine at another institution.
Asynchronous by default: Actions and inter-agent messaging are non-blocking end to end, so agents coordinate without serializing on the slowest participant.
A small set of primitives: The primitives are deliberately small: agents, handles, an exchange, an executor. Academy imposes no coordination pattern of its own, so what you build is not limited to the shapes a chat-oriented framework supports.

Evidence

Where Academy is being used

Deployments built on Academy by teams at Argonne, Oak Ridge, the University of Chicago, and the WHO African region. Only applications marked Production or Finished are listed.

World Health Organization African region Epidemiology PDX — Preparedness Data ExchangeProduction 3 agents · 3 nodes · federated
Oak Ridge National Laboratory Botany OPALProduction AWS to Frontier (OLCF) · federated
Argonne National Laboratory Medicine Chelator designProduction 9 agents · 9 nodes
Argonne National Laboratory General AISAC — AI Scientific Assistant CoreProduction Aurora (ALCF) and Perlmutter (NERSC) · federated
Argonne National Laboratory Materials science Electrolyte designFinished 32 agents · 2 nodes
Argonne National Laboratory / University of Chicago General Federated Co-ScientistFinished 10 agents · 7 nodes · federated

World Health Organization African region Epidemiology

Disease surveillance for early outbreak intelligence

PDX — Preparedness Data ExchangeProduction

Three cooperating agents run the surveillance pipeline. A Monitor agent polls a remote disease-surveillance API and classifies newly detected signals; a Review agent evaluates each alert against recent surveillance activity, estimating severity and geographic scope; a Notification agent routes the result to the relevant entities.

3 agents · 3 nodes · federated

Oak Ridge National Laboratory Botany

Plant phenotyping at exascale

OPALProduction

A multi-week APPL campaign images more than 10,000 plants across eight modalities, producing terabytes of data. A conversational Co-scientist agent on AWS builds a structured analysis plan with the scientist, then messages a Compute agent on Frontier, which stages the data and runs analysis through Parsl. Splitting the two keeps the co-scientist reachable while the compute agent works behind the batch scheduler.

AWS to Frontier (OLCF) · federated An Agentic AI Framework to Accelerate Scientific Discovery in Plant Phenotyping →

Argonne National Laboratory Biology

Designing binders for undruggable proteins

StructBioReasonerProduction

Intrinsically disordered proteins lack a stable fold, so conventional structure-based drug design has nothing to target. A Supervisor agent launches parallel Director agents onto remote HPC systems, each targeting a different potential interface; Directors launch sub-agents to manage tool calls, and each individual call runs as a stateless function.

Of 787 designed and validated candidates for Der f 21, over 50% outperformed the human-designed reference binders. In production it screened 11 million potential binders. 50 agents · 2,000 nodes Scalable Agentic Reasoning for Designing Biologics Targeting IDPs (PASC '26) →

Argonne National Laboratory Medicine

Drug design for cancer treatment

Chelator designProduction

Experiment manager agents use an LLM with a retrieval pipeline to hypothesize what makes a good chelator, a molecular generation model to propose molecules consistent with those hypotheses, and a fast physics code to screen them. Optimizer agents then evaluate promising candidates against an increasingly expensive panel of physics codes, and feed the results back to improve the surrogate, and through it the next round of hypotheses.

9 agents · 9 nodes

Argonne National Laboratory General

A general-purpose scientific assistant

AISAC — AI Scientific Assistant CoreProduction

AISAC centralizes its reasoning in a single planning workflow, then reaches distributed resources by calling specialized agents over the Academy exchange through an MCP server. Academy carries that traffic over its own authenticated exchange, because serving an MCP endpoint inside those facilities is difficult or prohibited. Teams wrap their components as agents and AISAC coordinates across them.

Aurora (ALCF) and Perlmutter (NERSC) · federated

Argonne National Laboratory Materials science

Electrolyte design for organic batteries

Electrolyte designFinished

An agent forest in which Experimenter agents propose molecules against competing design criteria and run simulations to calculate their properties. Each is launched with a different search direction and they collaborate by reading and writing to a shared blackboard.

LLM-driven search proved more sample-efficient than screening, finding better molecules from far fewer simulations. Adding agents did not speed it up proportionally, though, and collaboration between them degraded as their number grew. 32 agents · 2 nodes

Argonne National Laboratory / University of Chicago General

Federating the Co-Scientist

Federated Co-ScientistFinished

Instead of one monolithic AI collaborator, the system splits decision-making across separate agents, each deployed where its work is: next to instrumentation, in HPC facilities, beside data stores, or in the cloud for cross-site synthesis. A Provenance agent makes the outer loop introspectable, so it is possible to ask where and when a hypothesis was discarded.

10 agents · 7 nodes · federated Beyond Centralized Labs: Federating the Co-Scientist (SCA/HPCAsia '26) →

How to cite Academy

Empowering Scientific Workflows with Federated Agents

Alok Kamatar, J. Gregory Pauloski, Yadu Babuji, Ryan Chard, Mansi Sakarvadia, Daniel Babnigg, Kyle Chard, and Ian Foster

2026 IEEE International Parallel and Distributed Processing Symposium (IPDPS), pp. 1403–1418

DOI arXiv BibTeX

Community

Getting involved

Ask a question

Discussion and help getting started happen in the Academy Slack workspace. Bugs and feature requests go in the issue tracker; common problems are covered in the FAQ.

Community call

A fortnightly call where contributors present work in progress. The next topic, its abstract, and how to get the Zoom link are all on the calls page.

APeX Summit

The annual community meeting shared with Parsl and Globus Compute. APeX 2026 is a hybrid meeting on September 14–15, 2026, in person in Chicago.

Contribute

Development happens entirely in the open under the MIT license: code, issues, and planning alike. The contributing guide covers the fork, branch, and pre-commit workflow.

Latest

News & blog

All news & blog posts

Jul 2026 Event