What Ad-Hoc Teamwork Research Tells Enterprise Architects About Building Agents That Collaborate With Humans They Have Never Seen Before

Enterprise agent deployments are routinely designed around a fiction: that the humans working alongside the system will behave predictably, perform at a consistent skill level, and remain in post long enough for the agent to learn their patterns. In practice, workflows involve rotating staff, contractors stepping in mid-project, and operators whose proficiency varies by task type and fatigue state. When the assumed partner model diverges from reality, most production agents do not fail loudly. They fail silently, assigning tasks to humans who cannot complete them, generating plans that depend on capabilities the partner does not have, and degrading gracefully until someone notices the output quality has dropped. Research into ad-hoc teamwork offers a more honest design pattern for this problem.

The Core Problem: Fixed Partner Assumptions in Variable Environments

Most multi-agent system designs treat the human operator as a known quantity. Capability profiles are set at deployment, sometimes derived from role-based access controls, sometimes from onboarding assessments, and rarely updated after go-live. This works well enough when the same trained operator runs the same workflow every day. It breaks down the moment that assumption is violated.

The failure mode is not dramatic. The agent continues to function within its own logic. What changes is the quality of task allocation: the agent assigns actions to a partner who lacks the skill, the partner either skips the step or executes it poorly, and the downstream plan proceeds on a false premise. The gap between the agent's model of its partner and the partner's actual capability is the core source of degradation in human-agent teaming.

This is precisely the problem that ad-hoc teamwork research addresses. The field asks how an agent should behave when it is dropped into collaboration with a partner it has never encountered, cannot pre-train on, and must assess in real time from observed behaviour alone.

Capability Estimation Without Pre-Training

The standard response to unknown partners is to pre-train on a population of possible partner types and match observed behaviour to the closest type at runtime. This works when the deployment population is stable and bounded. It fails when partners are genuinely novel, which is the common case in enterprise environments where staff turnover, role changes, and external contractors continuously introduce new partner profiles.

Tisnikar et al. (arXiv 2026) propose a different approach in their CE-CM framework. Rather than matching to a known type, the agent infers a task-invariant capability vector for each partner by observing what actions they successfully complete across tasks. The capability vector is not task-specific. It represents the partner's underlying ability to execute action classes, which transfers across different task contexts. This is a meaningful architectural distinction because it means the agent does not need to observe the partner on every possible task before it can form a useful model.

The inference mechanism is approximate Bayesian. The agent maintains a distribution over possible capability states and updates that distribution as it observes partner behaviour. Critically, the method requires no pre-training on a partner population. It builds its model from a small number of observed task interactions and refines it online as more evidence accumulates.

Accounting for Suboptimal and Diverse Human Behaviour

A capability estimator that assumes partners always behave optimally will consistently underestimate what humans can do. When a skilled operator takes a non-standard route through a task, a system calibrated to optimal trajectories will read that deviation as evidence of lower capability. Over time, it will assign that operator progressively less demanding work, creating a feedback loop that further reduces the observable evidence of their actual skill.

Tisnikar et al. (arXiv 2026) address this directly with CE-CM-Div, an extension that evaluates capability hypotheses against a diverse set of planner rollouts rather than a single optimal trajectory. The intuition is that humans accomplish goals through varied strategies, and a capability model that only recognises one valid path will misread legitimate variation as incompetence. In their offline human study of 225 trajectories from 15 participants, CE-CM-Div substantially improved capability estimates over the baseline method, which is a result that has direct implications for any system where human operators are not following scripted procedures.

The commercial implication is straightforward. Systems that penalise human operators for non-standard but effective behaviour will progressively deskill the human role in the workflow. A capability model that accommodates behavioural diversity maintains a more accurate picture of what the human partner can contribute, which produces better task allocation decisions over the life of the deployment.

Architectural Implications for Multi-Agent System Design

Decentralised Execution Under Uncertainty

The CE-CM framework frames the collaboration problem as joint planning with decentralised execution under hidden partner capabilities. This framing matters architecturally because it acknowledges that the agent cannot fully observe what its partner will do before committing to a plan. The agent must make allocation decisions under uncertainty and update its model as execution proceeds.

For enterprise architects, this means the planning layer needs to be designed around uncertainty rather than certainty. Plans should encode the agent's current best estimate of partner capabilities alongside a confidence level, and task allocation decisions should be revisable mid-execution as new observations arrive. This is a different design requirement from a system that locks in a plan at the start of a workflow and executes it deterministically.

Online Belief Refinement

The online refinement property of CE-CM is particularly relevant for deployments where partner capability is not static. Operators improve over time, fatigue affects performance within a shift, and capability profiles change when staff take on new responsibilities. A system that updates its partner model only at deployment boundaries will accumulate model error between updates.

Designing for online belief refinement means the agent's partner model is a live data structure, not a configuration file. It requires an inference pipeline that runs continuously alongside task execution, a mechanism for weighting recent observations appropriately, and a way to detect when a capability estimate has shifted enough to warrant replanning. These are non-trivial engineering requirements, but they are the conditions under which the system maintains accuracy in variable environments.

Interpretable Capability Representations

Capability vectors are interpretable in a way that neural partner embeddings are not. An architect can inspect the vector, understand which action classes the system believes the partner can execute, and trace how that belief was formed from observed behaviour. This matters for audit, for debugging allocation failures, and for building operator trust in the system's decisions.

Companion piece to our broader work on human-agent workflow design. See The Human Bottleneck in Multi-Agent Systems for a practical guide to restructuring oversight and approval governance when agents operate faster than the humans managing them.

What This Means for Enterprise Agent Deployment

The practical design shift required here is from static partner profiles to probabilistic partner models that update continuously from observed behaviour. This is not a research aspiration. The CE-CM approach demonstrates that useful capability estimates can be formed from a small number of task observations, without population pre-training, and that those estimates improve meaningfully when the model accounts for behavioural diversity rather than assuming optimal execution.

For teams building agents that will operate in environments with rotating staff or variable operator skill, the immediate architectural question is where the partner model lives and how it is updated. If the answer is that it lives in a configuration file updated by an administrator, the system is not equipped for the environments it will actually encounter. If the answer is that it lives in an inference pipeline that updates from task-level observations, the system has the structure to adapt.

The secondary question is what the agent does with an uncertain capability estimate. An agent that withholds task assignments until it has high confidence in partner capability will be too conservative in novel situations. An agent that ignores uncertainty will make poor allocations early in a deployment. The right design sits between these positions: commit to a plan based on current best estimates, flag allocations that depend on unconfirmed capabilities, and revise as evidence accumulates.