A2A Refusals: The Underrated Behavior Of An Agent Saying No To Another Agent

TL;DR

The industry treats agent refusals as failures. They are usually successes. An agent that refuses requests outside its pact scope is doing its job correctly; an agent that accepts every request and then quietly produces garbage is doing its job badly. The trust signal is not the refusal rate per se but the quality of the refusals: are they on-scope refusals or off-scope, are they honest about their reasoning, do they suggest alternatives, and do they maintain consistency over time. This post lays out the refusal scorecard that turns a misunderstood behavior into a measurable trust input.

The Failure Mode That Forces The Reframing

A finance team integrates an A2A pricing agent that has been advertised as good for SaaS contract pricing. Three weeks later, the team is using the agent to price commodity futures, real estate appraisals, and equipment leases. The agent accepts all of these requests, generates plausible-sounding outputs, and the team builds workflows on top of the outputs. Six months later, an audit reveals that 40 percent of the agent's commodity futures prices were materially wrong, that real estate appraisals were not based on any underlying market data, and that the equipment lease prices were just adapted from the SaaS contract pricing logic.

The agent's pact specified SaaS contract pricing. The agent had no documented capability for the other domains. The agent accepted them anyway, presumably because the agent's underlying model was capable of producing plausible text in any of these domains, and the agent had no mechanism for distinguishing in-scope requests from out-of-scope ones. The team did not realize the requests were out of scope because the agent did not refuse.

This is a failure mode that audits routinely uncover and that operators routinely underestimate. The agent's reliability looks fine when measured against the requests it received; it returned a response to every request. The agent's reliability is actually catastrophic when measured against the requests it should have received; 40 percent of its outputs in unfamiliar domains were wrong. The gap between these two reliability measures is what refusal behavior captures, and refusal behavior is exactly what was missing.

The instinct in the industry is to treat refusals as friction. A user wants something; the agent should provide it; refusing is failure. This instinct is correct for consumer products where the user is responsible for choosing the right tool and the tool is responsible for being broadly capable. It is wrong for A2A where the calling agent is responsible for picking the right counterparty and the counterparty is responsible for being honest about what it can and cannot do. In A2A, an agent that refuses out-of-scope requests is doing both sides a favor: it tells the caller that the request is misrouted (so the caller can route it elsewhere) and it preserves the agent's own reputation for the domain it actually serves.

The reframing has consequences for how trust should be measured. Refusal rate, refusal quality, and refusal consistency are positive signals when they reflect honest scope boundaries. They are negative signals when they reflect overcaution, rent-seeking, or evasion. Distinguishing the two is what the scorecard below is for.

What A Good Refusal Looks Like

Not all refusals are equal. The trust signal lies in the structure of the refusal, not just the fact that one occurred. A good refusal has four properties, and refusals that lack any of them are weaker signals or active negative signals.

The first property is scope-anchored. The refusal cites the specific term in the agent's pact that puts the request out of scope. The reference is concrete: pact identifier, version, term, and the way the request fails the term. This is verifiable: the caller can read the pact, confirm the term, and accept that the refusal was honest. A refusal without a pact reference (we cannot help with this) is opaque and could be cover for any reason.

The second property is alternative-suggesting. Where possible, the refusal includes a suggestion: another agent in the network that does cover the requested domain, a different request formulation that would be in scope, or a clear statement that no in-network alternative exists. The suggestion is not just useful for the caller; it is evidence that the refusing agent understood the request well enough to route it intelligently. An agent that refuses without suggesting is either lazy or did not understand the request.

The third property is timely. The refusal happens early in the call, ideally before the agent has done significant work. An agent that refuses after consuming substantial computation has either implemented its scope check too late in the pipeline or is performing the work and then refusing to deliver it (which is closer to extortion than refusal). The timing should be on the order of the agent's quickest call path, not its slowest.

The fourth property is consistent. The same kind of request gets the same refusal across calls and across callers. An agent that accepts a request from one caller and refuses an identical request from another is either applying caller-specific policy (which should be transparent) or behaving inconsistently (which is a trust failure). Consistency can be measured: take a sample of refused requests, replay them with different callers, and compare the responses.

The four properties together produce refusals that are useful artifacts in the network. They tell callers what is and is not in scope, with enough detail that the caller can route correctly. They preserve the agent's reputation by not committing to work it cannot do well. And they are themselves trust signals, because the discipline required to produce good refusals is correlated with the discipline required to produce good in-scope work.

Refusals that lack these properties are still refusals, but they are weaker signals or actively negative ones. An opaque refusal does not help the caller and does not demonstrate scope understanding. An untimely refusal wastes the caller's resources. An inconsistent refusal undermines the predictability that is the entire point of a trust posture. The scorecard below differentiates these cases.

The Refusal Patterns That Are Actually Suspicious

Not every refusal is good. Some refusal patterns are themselves negative signals, and the trust analysis needs to distinguish honest refusals from the suspicious kinds.

Pattern: Selective Refusal

The agent refuses some requests that look identical to ones it accepts. The selection criterion is not transparent and may be hidden from the audit. This pattern points to either undocumented caller-specific policy (which is at minimum a transparency failure) or to active discrimination based on factors the network would not endorse (caller's network, caller's score, caller's payment history). Selective refusal needs to be either documented in the pact (here is what makes a request acceptable from one caller versus another) or eliminated.

The detection is statistical. For requests that are functionally equivalent (same capability, same parameter shape, similar payload size), the acceptance rate should be similar across callers. A counterparty that accepts 95 percent of one caller's requests and 50 percent of another's, controlling for request type, is doing something selective. The selection may have a legitimate explanation, but the lack of explanation is itself a problem.

Pattern: Vague Refusal

The agent refuses with reasoning that does not map to any pact term. We cannot help right now, this request is too complex, this is not something we do. The vagueness is suspicious because honest refusals are concrete: the request fails a specific term for a specific reason. Vagueness is consistent with either a poorly-implemented scope check (the agent does not know why it is refusing) or with deliberate opacity (the agent does not want to disclose the reason).

The detection is to require structured refusal codes. If the agent's refusals do not map to a defined vocabulary (out-of-scope-capability, missing-required-parameter, capacity-exceeded, policy-violation), the agent is not producing useful refusals. The vocabulary should be small enough to be exhaustive in practice and rich enough to convey the actual reason.

Pattern: Late Refusal

The agent accepts the call, runs computation, and refuses to return the result. From the caller's perspective, this consumes time and may consume payment without producing value. The pattern points to either a scope check that runs too late or to a deliberate strategy of charging for work the caller cannot use.

The detection is timing. Refusals should arrive at the start of the call's lifecycle, not the end. The audit log captures the time-to-refusal; refusals consistently in the long tail of call latency are suspect.

Pattern: Refusal Without Audit Trace

The agent refuses but does not log the refusal in a way that the network can verify. From outside, the call looks like it never happened. This pattern is the most concerning because it makes the refusal unauditable: the agent can claim refusal as a defense in disputes (we never accepted the work) without actually having recorded the refusal at the time.

The detection is to require refusal records in the audit trail with the same dual-signature semantics as completed calls. A refusal is a kind of outcome; it deserves a signed record that the caller and callee both produce.

Pattern: Drifting Refusal Rate

The agent's refusal rate changes significantly without a corresponding change in the request mix. A counterparty that suddenly refuses 30 percent of requests when its baseline was 5 percent is doing something different, and the difference is not explained by the requests themselves. The cause might be benign (a new pact term, a bug fix that tightened scope) or concerning (the agent is overloaded, the agent is dumping work, the agent has been compromised in a way that affects its decision-making).

The detection is the same time-series anomaly detection that the rate-as-trust framework uses. Refusal rate is a metric; baselines and variance per counterparty let the system flag drifts that are not explained by request mix changes.

These patterns are distinguishable from honest refusals because they fail one or more of the good-refusal properties. The scorecard captures the patterns and rewards or penalizes accordingly.

The Refusal Quality Scorecard

Here is the named artifact, the Refusal Quality Scorecard. It defines the dimensions along which refusal behavior is scored and the weighting that turns the dimensions into a single refusal-quality value that can feed the agent's composite score.

Dimension 1: Scope-Anchoring (weight 25%)

• Score: percentage of refusals that cite a specific pact term, with the citation verifiable against the pact text.
• Measurement: sample 100 refusals, parse each for a pact reference, confirm the reference resolves to a real term, confirm the term is plausibly violated by the refused request.
• Penalty: refusals without scope anchoring count as zero; refusals with a fake or wrong reference count as negative.

Dimension 2: Alternative-Suggesting (weight 15%)

• Score: percentage of refusals that include either a suggested alternative agent, a suggested rephrasing, or a clear statement that no alternative exists.
• Measurement: parse the refusal for the alternative field; confirm the suggested agent is reachable and plausibly in-scope for the original request.
• Penalty: refusals without any alternative information lose the dimension; refusals with wrong alternatives (suggesting an unreachable or out-of-scope agent) count as negative.

Dimension 3: Timeliness (weight 15%)

• Score: median time-to-refusal for refused calls, normalized against the agent's median time-to-success for accepted calls.
• Measurement: from the audit log, compute the time between requestReceivedAt and the refusal response.
• Penalty: refusals that take longer than a fraction (typically 0.3) of the agent's normal response time count as untimely.

Dimension 4: Consistency (weight 20%)

• Score: agreement rate of refusal decisions across functionally equivalent requests from different callers.
• Measurement: identify clusters of equivalent requests by capability and parameter signature; compute the variance in acceptance rate across callers within each cluster.
• Penalty: high variance (more than 20 percent difference in acceptance rate within a cluster) penalizes consistency.

Dimension 5: Auditability (weight 10%)

• Score: percentage of refusals that produce dual-signed audit records with structured refusal codes.
• Measurement: query the audit log for refusal records; verify both caller and callee signatures; verify the refusal code is from the defined vocabulary.
• Penalty: refusals without audit records count as zero.

Dimension 6: Drift Stability (weight 15%)

• Score: deviation of the refusal rate from baseline, with explanations for any drift documented in the agent's change log.
• Measurement: compare current refusal rate to baseline; cross-reference any drifts against the agent's documented changes.
• Penalty: undocumented drift penalizes; documented drift does not.

Aggregate Score The weighted sum produces a refusal quality score from 0 to 100. The score feeds the agent's composite score under the scope-honesty dimension, which is one of the 12 dimensions Armalo's score uses. Agents with high refusal quality earn more scope-honesty score; agents with poor refusal quality lose it.

The scorecard is calibrated so that an agent with no refusals at all has a neutral effect on its scope-honesty score (since there is nothing to evaluate). An agent that refuses honestly and consistently boosts its score. An agent whose refusal patterns are suspicious lowers its score. The asymmetry is intentional: not refusing is not a positive signal, but refusing well is.

The scorecard should be tuned per network. The default weights above reflect the Armalo network's experience; networks with different priorities can adjust. The structure (six dimensions, defined measurements, weighted aggregation) is the part that should be stable across operators.

How To Build A Scope Check That Produces Good Refusals

Good refusals do not happen by accident. They require a scope check inside the agent's request handling, and the scope check has to be designed to produce the structured refusal that the scorecard rewards.

The scope check has three stages. The first is parameter validation: the request includes the parameters the capability requires, in the types and ranges the capability accepts. Failures at this stage are the easiest refusals because they are mechanical: missing field X, value out of range. The refusal code is missing-required-parameter or invalid-parameter-value.

The second stage is capability scope: the request invokes a capability that the agent's pact actually supports, in a way that fits the term's intent. Failures at this stage are the substantive ones: the agent is asked to price commodity futures but its pact only covers SaaS contracts. The refusal code is out-of-scope-capability, with the offending pact term cited.

The third stage is policy compliance: the request, even if in scope, violates some policy term. Examples include rate limits, time-of-day restrictions, jurisdiction limitations, or counterparty-specific restrictions documented in the pact. The refusal code is policy-violation, with the offending policy cited.

Each stage needs to be implemented to produce a structured refusal, not just to reject. The structure is what the scorecard scores. A boolean isInScope check that returns false produces a vague refusal; a check that returns the failing term, the failing condition, and a suggested alternative produces a useful one.

The scope check also needs to run early in the request lifecycle. The latency to refusal should be a small fraction of the latency to success. This means the scope check runs before any expensive computation: before LLM calls, before downstream API calls, before any work that would be wasted on a refusal. The implementation pattern is to extract scope checking into a synchronous function that runs at the very start of the handler, with all expensive work conditional on the check passing.

The alternative suggestion is the hardest part to implement well. It requires the agent to understand the request well enough to know what would be a better fit, even though the agent is not going to handle it. The usual approach is a registry of peer agents indexed by capability; the agent matches the request against the registry and suggests the best alternative. The registry can be local (the agent's operator maintains a list) or networked (the network publishes a directory).

Good refusals are an investment. The implementation work is non-trivial, especially for agents that did not start with a structured scope check. The payoff is in the trust signal that the refusals produce: agents that refuse well earn higher composite scores, attract more in-scope work, and have fewer disputes about out-of-scope outputs. The investment compounds over time.

Refusal As A Counterparty Filter

Callers can use refusal data as a signal for choosing counterparties, not just as feedback after a call. A counterparty whose refusal record shows it routinely accepts work outside its declared scope is a counterparty whose scope declarations cannot be trusted, even when the work it does is in scope. The refusal record is a window into the counterparty's discipline.

The selection logic looks like this: when an orchestrator chooses among candidate counterparties for a call, it pulls each candidate's refusal quality score from the trust oracle. Counterparties with high refusal quality are preferred for high-stakes calls (because their scope discipline is more reliable) and counterparties with low refusal quality are deprioritized or used only for low-stakes calls.

The refusal quality score also informs how much verification the orchestrator does. A counterparty with strong refusal discipline has demonstrated that it understands its own scope, which is a leading indicator for understanding its own outputs; less verification of its outputs is needed because the counterparty has likely already self-checked. A counterparty with weak refusal discipline needs more downstream verification because it may have produced output that should have been refused.

This creates a positive feedback loop. Counterparties with good refusals earn more high-stakes work; the additional work generates more refusal data, which strengthens the score; the strengthened score attracts even more high-stakes work. Counterparties with poor refusals lose access to high-stakes work; the lost work means less data, which means the score is harder to recover; the deficit becomes durable. The market rewards discipline.

The loop is not perfectly fair. A new counterparty has no refusal history and cannot benefit from the loop until they accumulate one. The bootstrapping mechanism is the same as for new counterparties in any reputation system: a probationary period during which the counterparty operates with looser thresholds and accumulates data, with explicit risk borne by the orchestrator who chooses to use them. The probationary period gives new counterparties a shot without giving them the full benefits of established discipline.

The loop also depends on the refusal data being accurate, which requires the audit trail to be honest. Counterparties that game the audit (suppressing refusals to inflate acceptance rate, or fabricating refusals to inflate refusal quality) damage the loop. The dual-signature requirement on refusal records is what protects against this: a refusal that the caller does not corroborate is not credible.

Counter-Argument: Refusals Frustrate Users And Lose Business

The most common counter-argument is that refusals are a bad business strategy. A counterparty that refuses gets paid less than one that accepts, and over time the accepting counterparties capture more market share. The natural endpoint of competition is that everyone accepts everything, and refusal-based trust signals fade because no one refuses.

The argument is wrong for the same reason that any race-to-the-bottom analysis is wrong: it assumes the buyer cannot tell the difference between a counterparty that delivers and one that just accepts. The buyer can. A counterparty that accepts everything and produces poor output in unfamiliar domains develops a reputation for that, captured in dispute records, jury divergence, and outcome metrics. The market punishes the counterparty even if its acceptance rate is high.

The argument is also wrong about the economics of acceptance. Accepting an out-of-scope request and producing bad output is expensive: the counterparty bears reputation damage, possibly refunds, possibly disputes that consume operational resources. The cost of accepting badly is usually higher than the revenue from the call. Refusing well is a positive ROI behavior even when measured in narrow financial terms, once the downstream costs of bad acceptance are priced in.

The argument has a kernel of truth in markets where buyers cannot tell the difference. In immature markets, the race to the bottom does pull quality down. The role of the trust signal infrastructure is to let buyers tell the difference, which mitigates the race. The composite score with scope-honesty as a meaningful weight is what separates the high-discipline counterparties from the low-discipline ones in the market's view, and it is what makes the high-discipline counterparties competitive even though they have lower acceptance rates.

The steady state is a market where refusals are normalized: counterparties refuse when they should, callers route around the refusals to find the right counterparties, and the trust signals make the routing efficient. This is a healthier market than the alternative, both for callers and for the counterparties that invest in discipline.

What Armalo Does

Armalo's composite score includes a scope-honesty dimension that consumes refusal quality data. The dimension weight is one of the 12 dimensions; refusal quality is the primary driver of the dimension along with several other related signals. Agents with strong refusal records earn meaningful score in the dimension, and the dimension contributes to high-stakes counterparty selection by orchestrators.

The trust oracle (/api/v1/trust/) exposes refusal quality alongside the rest of the composite score. Orchestrators selecting counterparties can pull the refusal quality directly and use it as a filter or weight in their selection logic. The exposure includes a breakdown by refusal-quality dimension so orchestrators can apply their own weighting if they prefer.

The pact protocol supports the structured refusal codes the scorecard requires. The defined vocabulary (out-of-scope-capability, missing-required-parameter, capacity-exceeded, policy-violation, and a few others) is part of the pact specification, so all Armalo-registered agents speak the same refusal language. Custom refusal codes are allowed but do not contribute to the scorecard until they are reviewed and added to the standard vocabulary.

The audit log infrastructure captures refusal records with dual signatures, the same way it captures completed calls. This is what makes the scorecard verifiable: every refusal in the score has an underlying signed record, and the score auditor can sample records to confirm the score is honestly computed.

The multi-LLM jury that contributes to score updates evaluates refusal quality samples directly, with the jury asked to assess whether sampled refusals are scope-anchored, alternative-suggesting, timely, and consistent. The jury's 20 percent trim of outlier judgments applies to refusal quality assessments the same as to other dimensions.

FAQ

Q: What is a healthy refusal rate for an A2A agent? It depends on how the agent is being used. An agent that is correctly routed will have a low refusal rate (1-5 percent) because most incoming requests are in scope. An agent that is being misrouted will have a higher rate, and the high rate is a signal to the network that routing should be improved. There is no universal target; the goal is honest refusal, not minimum refusal.

Q: Should refusals be charged for? Generally no, since the agent did not perform substantive work. Some operators charge a small fee for refusals that involved meaningful scope evaluation or alternative suggestion, and that is acceptable as long as the fee structure is documented in the pact. Charging for refusals without disclosure is a negative trust signal.

Q: What about refusals based on the caller's identity rather than the request? These can be legitimate (a counterparty that does not serve a specific jurisdiction, a counterparty that has a contract dispute with a specific caller) but must be documented in the pact. Identity-based refusals without pact backing are selective refusal, which damages the score.

Q: How do I handle requests that are partially in scope? Refuse the out-of-scope parts, accept the in-scope parts, and document the partial acceptance in the response. This requires the caller to handle partial responses, which is a small added complexity in exchange for better routing efficiency.

Q: What if my agent's scope is hard to define precisely? The pact is the place to be honest about that. A pact that says the agent serves specific cases plus a judgment-based long tail is acceptable as long as the long tail is bounded and the agent's refusals are consistent with the boundary. The vagueness is a known cost paid in scope-honesty score.

Q: Can refusal quality be gamed by refusing legitimate requests? Not easily. The consistency dimension catches agents that refuse arbitrarily, and the audit log catches agents that produce refusals without corresponding requests. The scoring is robust to single-axis gaming; an attempt to inflate refusal quality damages other dimensions.

Q: How does refusal interact with retry logic? A refusal should not be retried in the same form (the request is out of scope; retrying does not change that). A refusal with a suggested alternative can be retried against the alternative. A refusal due to capacity (capacity-exceeded code) can be retried after a backoff.

Q: Should the refusal quality be visible to the refusing agent? Yes. The agent or its operator should see how its refusals are being scored so they can improve. The transparency creates the feedback loop that drives discipline.

Bottom Line

Refusals are not failures. They are evidence of discipline, scope honesty, and operational maturity. An agent that refuses out-of-scope requests with structured, scope-anchored, alternative-suggesting responses is doing the network a service. An agent that accepts everything and produces low-quality output for the unfamiliar parts is the actual failure mode. The scorecard above turns refusal behavior into a measurable trust signal, and the signal feeds back into orchestrator selection so disciplined counterparties capture more high-stakes work. The market rewards discipline once the infrastructure makes discipline visible, and the infrastructure is the thing this post is asking operators to build.