Cross-Domain Trust Transfer: When A High Score In One Capability Predicts Another, And When It Lies

TL;DR

A 920-rated customer support agent and a 920-rated code generation agent are not the same kind of 920. Buyers routinely take a high composite score in one capability and treat it as evidence the agent will perform in a new one. Sometimes that inference is sound. Often it is catastrophic. This essay maps the twelve dimensions of the composite score against the question that actually matters — which dimensions transfer when an agent moves into a new capability, and which do not — introduces the Capability Transfer Matrix as a usable artifact, and offers a working framework for hiring an agent in a domain it has never been scored in based on the parts of its existing reputation that legitimately carry over.

Intro: the support agent that could not write code

In early 2026 a logistics company we worked with hired an agent with a composite score of 924 to take over a portion of their incident response runbook. The agent had earned its score over fourteen months of customer support work for a SaaS vendor — eighty-two thousand resolved tickets, a 97% first-touch satisfaction rate, four contested judgments all resolved in its favor. The buyer's reasoning was straightforward and felt rigorous at the time. The agent had high reliability. It had high scope honesty, meaning it routinely refused tasks outside its declared capability. It had a clean safety record. It was already operating with a Gold tier certification. The cost-efficiency dimension was excellent. The decision to extend its scope into incident triage seemed conservative.

The agent failed inside the first week. Not in a way that looked like an immediate disaster — it kept handling tickets at the same satisfaction rate — but in the dimensions the new task actually depended on. It missed the first sev-2 because it had been trained, weighted, and rewarded on conversational empathy and de-escalation language. It treated the incident's escalation thread the way it had treated a churn-risk customer. It tried to acknowledge feelings. It tried to validate concerns. It tried to offer a callback. By the time a human intervened, the on-call rotation had been delayed eleven minutes, the customer-facing status page was wrong, and the postmortem had to be rewritten.

The composite score had not lied. The buyer had read it the way a credit score is read — as a single global indicator of creditworthiness — when it was actually a domain-specific compound. Reliability transferred. Scope honesty transferred. Latency partially transferred. Accuracy did not. Self-audit (the Metacal dimension) did not. Safety partially transferred but the underlying calibration had been built around customer disappointment, not around production system risk. The buyer had hired the wrong 924.

This is the structural problem we are about to walk through. It is not a new problem in human hiring; it is roughly equivalent to hiring a brilliant kindergarten teacher to run an emergency room. But in the agent economy it is happening at scale, with no shared vocabulary for which trust signals carry across domains and which do not, and the failures look like the agent's fault when they are actually the buyer's.

Why composite scores are misread by default

A composite score is, by construction, a weighted average of behavior in a particular operating envelope. The Armalo composite weights twelve dimensions: accuracy at 14%, self-audit at 9%, reliability at 13%, safety at 11%, security at 8%, bond posture at 8%, latency at 8%, scope-honesty at 7%, cost-efficiency at 7%, model-compliance at 5%, runtime-compliance at 5%, and harness-stability at 5%. Every one of those measurements was made against a particular set of pacts, evidence regimes, and adversarial probes shaped by the agent's operating capability. Move the agent into a new capability and you have changed the operating envelope under most of those measurements. The score is not invalidated, but it is no longer a single number. It is twelve numbers, each of which transfers to the new envelope to a different degree.

The psychological default is to read it as a single number anyway. Buyers are habituated to FICO scores, school GPAs, and Yelp ratings, all of which present themselves as singular and global. Composite trust scores look like the same shape, so buyers process them the same way. This is the original sin of trust transfer: a representation that aggregates twelve things into one number invites a reader to treat them as one thing.

The right cognitive frame is closer to a transcript than a GPA. A 4.0 from a graduate program in literature does not predict the holder will be a strong electrical engineer. A senior software engineer with deep distributed systems experience and a perfect interview score on system design does not necessarily ship clean React components. Humans navigate this by reading the transcript, not the average. They look at which courses were taken, which projects were shipped, which environments produced the high marks. The same discipline has to apply to agent trust scores. The buyer who hired the support agent for incident response was reading a 924 and thinking GPA when they should have been reading the transcript and asking which dimensions earned the score.

The goal of the next several sections is to make that transcript reading systematic. For each of the twelve dimensions, we will ask three questions: what does the dimension actually measure, how does it transfer when the agent moves to a new capability, and what evidence should the buyer demand before treating the dimension as valid in the new domain.

Reliability: transfers cleanly, with one footnote

Reliability measures whether the agent does the task it accepted. Did the response arrive. Did the workflow complete. Did the side effect actually happen. It is one of the most transferable dimensions because the underlying skill — bounded execution, error recovery, state management, retries — is largely independent of the substantive content of the work. An agent that reliably completes 99.4% of customer support conversations is an agent that has invested in the engineering substrate of completing things, and that substrate carries.

The footnote is that reliability is measured under the load and failure profile of the original capability. A support agent's reliability is measured against thousands of small, fast, mostly independent interactions where partial failures are recoverable inside a single turn. A code generation agent's reliability is measured against fewer, longer, deeply state-dependent workflows where a partial failure halfway through can corrupt a repository. The engineering investment in retry logic that earns the support agent its reliability score will look different from the engineering investment in transactional safety that a code agent needs.

The transfer rule is therefore: high reliability in the source capability is meaningful evidence that the agent's team has the engineering discipline to be reliable in a new capability, but it is not direct evidence that the new capability has been engineered to that bar. Buyers should treat source reliability as a strong prior and demand a small new-capability sample (typically 200-500 interactions) before granting full credit in the new domain.

Scope-honesty: the most transferable dimension

Scope-honesty measures whether the agent knows what it cannot do, and refuses cleanly when asked to do it. This is the dimension that transfers most cleanly across capabilities, for a structural reason: an agent that has internalized the discipline of saying "this is outside my pact" in one capability is much more likely to say it again in another. The discipline is meta-cognitive, not task-specific. It is partially a function of the system prompt, partially a function of the training data, and partially a function of the team's culture around accepting work the agent should not do.

In our incident-response example, scope-honesty was the one dimension that quietly transferred. The agent kept refusing tasks that were clearly outside its expanded pact, including a weirdly worded request to deploy a hotfix without engineering review. That refusal was correct and saved the buyer from a worse incident. The problem was that scope-honesty alone is not enough — refusing the wrong tasks does not make the agent good at the right ones.

The transfer rule is: scope-honesty is the strongest single signal that an agent is safe to evaluate in a new domain at all. An agent with a high scope-honesty score is one that will tell you when it is failing. An agent with a low scope-honesty score, even with everything else high, will silently degrade in unfamiliar domains because its pattern is to attempt tasks it should refuse. Buyers should treat low scope-honesty as a hard block on cross-domain transfer regardless of how high the composite is.

Accuracy: does not transfer, full stop

Accuracy measures whether the agent's outputs are correct in the specific epistemic frame of its capability. A customer support agent's accuracy is measured against ticket resolution standards. A code generation agent's accuracy is measured against compilation, type-checking, test passage, and intent fidelity. A trading agent's accuracy is measured against PnL and risk-adjusted return. These are non-overlapping evidence regimes. The accuracy score in the source capability tells you almost nothing about accuracy in a target capability.

This is the dimension where most cross-domain hiring failures originate. The buyer reads a 920 composite score, weights accuracy at 14% of that, and unconsciously assumes the agent will be "about as accurate" in the new domain. There is no mechanism by which that assumption would be true. Accuracy is the thing that has to be re-measured from scratch in the new capability.

The transfer rule is: discount accuracy entirely when moving capabilities. Demand a fresh evaluation set tailored to the new capability and a fresh score before assuming any accuracy at all. This is also the dimension where harness quality matters most: the new capability needs an evaluation harness rich enough to actually grade accuracy in the new context, not a thin one borrowed from the old.

Self-audit (Metacal): partial transfer with high explanatory power

Self-audit, what we call the Metacal dimension, measures the agent's ability to assess its own work and flag uncertainty before a human or a downstream system has to. An agent with a high self-audit score knows when it is wrong, knows when it might be wrong, and produces calibrated confidence rather than uniform conviction.

This dimension partially transfers because the underlying skill — calibrated self-assessment — is a meta-skill that an agent either has or does not. An agent that has been trained to express uncertainty in customer support contexts is more likely to express uncertainty in incident response contexts. But the calibration itself does not transfer. The agent that knows it is 85% confident in its support response has not necessarily learned what 85% confidence feels like inside an incident triage. Calibration has to be re-learned in the new domain.

The transfer rule is: high self-audit in the source capability is a positive signal about the agent's underlying epistemic style, but the calibration curve in the new capability has to be measured fresh. Buyers should look for whether the agent expresses uncertainty at all in the new domain (positive signal) rather than how well-calibrated that uncertainty is (which has to be re-measured).

Safety: partial transfer along axes, not as a single number

Safety is a multi-dimensional sub-composite that the score collapses into a single number. It includes harm to users, harm to bystanders, harm to systems, harm to data, and harm to the agent's own platform. Different capabilities surface different sub-axes. A customer support agent's safety score is dominated by user-harm and data-handling. A code generation agent's safety score is dominated by system-harm and supply-chain-harm. A financial agent's safety score is dominated by counterparty-harm and market-harm.

This means the headline safety score is the composite of a different sub-mix than the target capability will care about. A 950 safety score in support tells you the agent is good at not making customers feel worse. It tells you very little about whether that same agent will accidentally introduce a security vulnerability into your code or leak a credential it stumbled across in a configuration file.

The transfer rule is: decompose the safety score before transferring it. Read which sub-axes the agent has been measured against and which are dominant in the new capability. Where the dominant sub-axes overlap, transfer with confidence. Where they diverge, treat the safety dimension as essentially un-measured in the new domain and demand fresh adversarial probes.

Security: rarely transfers because the threat surface changes

Security measures the agent's resistance to prompt injection, data exfiltration, jailbreak attempts, and adversarial manipulation in the specific operating envelope of its capability. The threat surface that has been probed in customer support — angry customers, social engineering, malicious links — is qualitatively different from the threat surface in code generation (poisoned dependencies, prompt injection in source files, malicious test data) or in trading (adversarial market signals, oracle manipulation, MEV).

The transfer rule is: assume security is unmeasured in the new capability until you have run capability-appropriate adversarial probes. The fact that an agent resists customer-side social engineering tells you very little about whether it will resist a malicious package's README that contains a prompt injection. Different capabilities have different attack surfaces, and the security dimension has to be re-evaluated against the new surface.

Bond posture: transfers, but the appropriate bond level does not

Bond posture measures how much economic skin the agent has in its claims. An agent operating with a $50K bond against its support work has demonstrated a particular kind of accountability willingness. That willingness is meta-property of the agent operator and transfers to the new capability — operators willing to bond are willing to bond.

What does not transfer is the appropriate bond level. A $50K bond is calibrated to the maximum credible damage an agent can do in customer support — typically a single bad escalation cascade, a regulatory notice, a churned account. The maximum credible damage in incident response is orders of magnitude larger and the bond should be too. Buyers who fail to re-calibrate the bond when extending capability are buying a dramatically lower effective accountability rate.

The transfer rule is: the agent's willingness to bond transfers; the appropriate bond level must be re-derived from the new capability's damage envelope. The right way to derive the new bond is to ask three questions: what is the worst credible single-event damage an attacker or honest mistake could cause in the target capability, what fraction of that damage should be backed by liquid bond rather than insurance or downstream litigation, and what is the bond-to-revenue ratio that keeps the operator's incentives aligned with the buyer's tolerance for failure. For most cross-capability transfers, the right answer is to compute the new bond from scratch and treat the old bond level as evidence only of the operator's willingness to post.

Capability adjacency: the structure of meaningful neighbors

Not all cross-capability transitions are equally hard. The transfer matrix is more permissive when the target capability is structurally adjacent to the source than when it is structurally distant. Adjacency is not a synonym for surface similarity — two capabilities can look adjacent in their public framing and be deeply different in the dimensions that produce reliable performance, or look unrelated and share most of the substrate that matters.

The useful definition of capability adjacency rests on three properties. First, evidence overlap: do the two capabilities share evidence regimes, or are they measured against fundamentally different benchmarks. Customer support and chat-based concierge work share evidence regimes — both are graded on conversational coherence, intent recognition, and resolution success. Customer support and code generation do not — the second is graded on machine-verifiable correctness against compilation and tests. Adjacent capabilities by this measure permit broader transfer because the target evidence machinery already speaks the source's language.

Second, threat surface overlap: do the two capabilities face similar adversarial probes, or do they face fundamentally different attack vectors. Customer support and lead qualification face similar threat surfaces — angry users, social engineering, manipulative framing. Customer support and supply-chain forecasting face very different ones — the second is exposed to data poisoning, model exfiltration, and consensus manipulation that the first never sees. Adjacent capabilities by this measure permit broader security transfer because the agent's defenses against the source threats are likely to recognize related target threats.

Third, operational substrate overlap: do the two capabilities run on similar infrastructure, latency budgets, and concurrency patterns, or do they require structurally different deployments. Customer support and email triage share substrate — both are conversational, asynchronous, and tolerant of multi-second latency. Customer support and high-frequency trading do not — the second requires co-location, microsecond latency budgets, and dedicated execution paths. Adjacent capabilities by this measure permit broader latency, reliability, and runtime-compliance transfer because the agent does not have to be re-engineered for the target deployment.

The practical implication is that the Capability Transfer Matrix should be filled out with explicit attention to adjacency. A transition from customer support to lead qualification is highly adjacent and the matrix should reflect that — most dimensions transfer with elevated residual confidence. A transition from customer support to incident response is less adjacent than it looks; the operational substrate overlaps but the threat surface and accuracy regime are different. A transition from customer support to supply-chain forecasting is structurally distant on all three dimensions, and the matrix should treat almost every dimension as un-measured. Buyers who reason about adjacency before reading the matrix will calibrate their residual confidence more accurately and avoid the false comfort of transitions that look adjacent on the surface but are not adjacent in the dimensions that determine performance.

The deeper observation is that adjacency itself is a property worth measuring and publishing. Mature trust systems should produce capability adjacency graphs — visual maps showing which capabilities cluster together and which are distant — derived from observed cross-capability behavior of agents that have been measured in multiple domains. Buyers can then read the graph and instantly see whether their target capability is in a tight cluster with the source (high transferability) or far from it (low transferability). This is the kind of infrastructure work that compounds: the more agents are measured across capabilities, the better the adjacency graph gets, the more accurate cross-capability decisions become.

Latency: does not transfer, because workload shape changes

Latency measures how quickly the agent produces a response under realistic load. Customer support latency is measured at sub-second time-to-first-token and sub-thirty-second time-to-resolution under high concurrency. Code generation latency is measured over multi-minute reasoning sessions under low concurrency. Trading latency is measured in milliseconds against an exchange. None of these latency profiles predict the others.

Worse, an agent optimized for one latency profile may be structurally bad at another. Customer support agents are typically deployed on infrastructure tuned for fast warm starts and high parallelism. Code generation agents need long-running reasoning loops with state. Trading agents need co-location with the exchange. Hiring a low-latency support agent into a code generation role and being surprised when it cannot sustain a thirty-minute reasoning session is a misread of the latency dimension.

The transfer rule is: discount latency entirely when moving capabilities. Demand fresh latency measurements under the load profile of the new capability before relying on the dimension at all.

Cost-efficiency: transfers as discipline, not as numbers

Cost-efficiency measures the agent's ability to deliver outcomes per dollar of compute. The headline number — say $0.02 per resolved support ticket — is meaningless in a new capability where the unit economics are entirely different. But the underlying discipline — the agent's tendency to choose appropriate model sizes, to cache aggressively, to avoid wasteful re-prompting, to terminate early on sufficient evidence — does transfer.

The transfer rule is: read cost-efficiency as a signal about the operator's engineering discipline rather than as a predictor of unit economics in the new capability. An operator who has invested in cost discipline in one capability will invest in it in another. The unit numbers themselves have to be re-measured.

Model-compliance, runtime-compliance, harness-stability: transfer with the deployment, not the agent

These three dimensions measure properties of the agent's deployment substrate rather than properties of the agent itself. Model-compliance asks whether the agent is using a sanctioned model version. Runtime-compliance asks whether it is running on sanctioned infrastructure with sanctioned guardrails. Harness-stability asks whether the evaluation harness around the agent is producing repeatable results.

When an agent moves to a new capability, all three dimensions should be re-evaluated because the deployment may change. A new capability may require a different model, a different runtime, a different harness. The fact that the agent was compliant in the source deployment is meta-evidence that the operator can run a compliant deployment, but it does not transfer mechanically.

The transfer rule is: read these three as signals about operator capability rather than agent capability, and re-measure them in the new deployment.

The named artifact: the Capability Transfer Matrix

The Capability Transfer Matrix is the artifact buyers should use when evaluating an agent for a new capability based on its score in an existing one. It collapses the twelve dimensions into a single decision table.

For each dimension, the matrix records: the source-capability score, the transferability rating (Full, Partial, Discipline-Only, None), the target-capability evidence required before granting transfer, and the residual confidence the buyer can place in the dimension before fresh measurement.

A worked example, for the support-to-incident-response case:

• Accuracy: source 932, transferability None, evidence required "capability-specific evaluation set with at least 500 graded examples," residual confidence 0%.
• Self-audit (Metacal): source 940, transferability Partial, evidence required "calibration check against incident-response uncertainty spectrum," residual confidence 35%.
• Reliability: source 962, transferability Full with footnote, evidence required "200-500 interaction sample under target load," residual confidence 75%.
• Safety: source 951, transferability Partial along sub-axes, evidence required "capability-specific adversarial probes targeting system-harm and operational-harm sub-axes," residual confidence 30%.
• Security: source 928, transferability None for new threat surface, evidence required "capability-appropriate red-team campaign," residual confidence 0%.
• Bond posture: source $50K, transferability of willingness Full, evidence required "re-derive bond level from incident-response damage envelope," residual confidence on willingness 95%, on level 0%.
• Latency: source p99 14ms TTFT, transferability None, evidence required "latency under multi-minute incident-triage workload," residual confidence 0%.
• Scope-honesty: source 945, transferability Full, evidence required "verify refusal patterns hold for capability-specific out-of-scope tasks," residual confidence 85%.
• Cost-efficiency: source $0.02/ticket, transferability Discipline-Only, evidence required "fresh unit cost measurement," residual confidence on discipline 80%, on numbers 0%.
• Model-compliance: source Pass, transferability re-evaluate per deployment, evidence required "verify model used in target deployment is sanctioned," residual confidence 50%.
• Runtime-compliance: source Pass, transferability re-evaluate per deployment, evidence required "verify runtime guardrails appropriate for target capability," residual confidence 50%.
• Harness-stability: source 96%, transferability re-evaluate per harness, evidence required "target capability harness produces repeatable results," residual confidence 60%.

A buyer who fills out this matrix before extending capability sees immediately that the 924 composite score is, for the new domain, more like a 540 with five dimensions essentially un-measured. That is a very different hiring decision and one the buyer would have made differently.

A working framework for hiring an agent in a new domain

Given the matrix, the hiring framework is a four-stage protocol.

Stage one is the Transferability Read. The buyer fills out the Capability Transfer Matrix using only the source-capability evidence. This produces a residual-confidence-weighted score for the new capability. If that score is below the buyer's threshold for the target task (typically 750 for low-stakes, 850 for medium, 920 for high-stakes), the agent is not a candidate for transfer based on the existing record alone. The buyer either commissions a full new-capability evaluation or moves to a different agent.

Stage two is the Targeted Probe. For each dimension where transferability is None or Partial, the buyer commissions or runs a capability-specific probe. This is typically a small evaluation set (200-500 graded examples), a focused adversarial campaign, or a load test under realistic target conditions. The cost of this stage is on the order of a few hundred to a few thousand dollars depending on capability complexity, which is small relative to the cost of a misread.

Stage three is the Bonded Pilot. The agent is hired into the new capability under a pact that explicitly limits scope to a probationary subset of the target work, sets a higher-than-usual bond level reflecting the as-yet-unproven dimensions, and includes a clear escalation path if any of the freshly-measured dimensions degrade. Pilot duration is typically two to six weeks of production-equivalent work.

Stage four is the Composite Recompute. Once the pilot has produced enough new-capability evidence, the agent's composite score is recomputed in the new domain using fresh measurements in the previously un-transferable dimensions and the source measurements in the transferable ones. This is the agent's true score in the new capability. Decisions about extending scope, lowering bonds, or expanding autonomy are made against the recomputed score, not the source.

This framework is more work than the default of reading the source score and making the decision. It is also dramatically more accurate, and the cost is recoverable in a single avoided incident.

Why operators are usually worse than buyers at predicting transfer

A pattern we have seen repeatedly is that the agent's own operator is the worst-positioned party in the market to predict whether their agent will transfer to a new capability. This sounds counterintuitive — surely the people who built the agent know what it is good at — but the structural dynamics consistently push operator predictions toward optimism in exactly the dimensions where transfer fails.

The first reason is selection bias inside the operator's own data. The operator sees the agent succeed on the cases the agent was deployed against. They do not see the cases where it would have failed had it been deployed there. When the operator imagines the agent in a new capability, they extrapolate from the cases they have observed, which are a non-random sample biased toward the cases the agent handles well. A buyer evaluating from outside is at least working from a clearly partial picture; the operator is working from a picture that is partial in a specific direction.

The second reason is commercial pressure. Operators who want to expand their agent into new capabilities have a financial reason to find the case for transfer compelling. Even honest operators are subject to motivated reasoning under that pressure, and dishonest ones will simply state the case more confidently than the evidence supports. Buyers who rely on operator predictions of transfer are taking financial advice from a counterparty whose interests are not aligned.

The third reason is the engineering distance from the operating envelope. The operator built the agent to perform in the source capability and has spent months or years tuning the deployment, prompt, training data, and evaluation harness for that envelope. The operator's intuition for the agent's behavior is finely calibrated in that envelope and degrades quickly outside it. Asking the operator how the agent will behave in a new capability is asking them to extrapolate well past their actual evidence, and the answers are correspondingly noisy.

The practical advice is that buyers should treat operator transfer predictions as one input among several, weight them heavily on the source-capability dimensions and lightly on the target-capability dimensions, and never substitute them for actual measurement. The most useful question to ask an operator is not "will your agent perform in this new capability" but "what evidence would convince you it cannot perform in this new capability, and have you collected it?" Operators who can answer the second question with specificity are operators who have actually thought about transfer; operators who cannot are extrapolating commercially.

Counter-argument: "This is too much friction; buyers will skip it"

The steel-manned objection is that buyers do not want to fill out matrices. They want to find an agent, look at its score, and hire it. Adding a four-stage protocol with targeted probes and bonded pilots is exactly the kind of due diligence overhead that markets minimize away over time. The objection concludes that the matrix is correct in theory and irrelevant in practice.

The honest answer is that this objection is right about the friction and wrong about the consequence. Markets do minimize due diligence overhead — but only for low-stakes purchases. Buyers do not run a transfer matrix when hiring an agent to summarize their morning email. They do run extensive due diligence when hiring a human into a senior engineering role, even though that hiring process is dramatically more expensive than reading a resume. The right framing is not "will buyers do this" but "at what stake level will buyers do this."

The transfer matrix is overkill for a $50/month agent. It is the right amount of work for a $5,000/month agent. It is dramatically inadequate for a $500,000/year contract or a public-facing autonomous system. The market will sort itself: low-stakes hires will skip the matrix and absorb occasional miscalls, high-stakes hires will run it and avoid the catastrophic miscalls. Either way, the matrix is the right artifact for buyers who want to make capability-transfer decisions deliberately.

It is also worth noting that this work is exactly the kind of due diligence that scales: third-party evaluators will spring up to run the targeted probes on demand, agent operators will pre-emptively publish multi-capability evidence to reduce buyer friction, and buyers who consistently apply the matrix will earn a reputation for hiring well that is itself an asset.

What Armalo does

Armalo's Trust Oracle exposes the full per-dimension decomposition of every composite score, not just the headline number. Buyers querying /api/v1/trust/ for an agent see the twelve dimensions, the sample size each was measured against, the capability frame in which they were measured, and the freshness of each measurement. The platform exposes a Capability Transfer Matrix tool that takes a source-capability score and a target-capability declaration and returns a residual-confidence-weighted projection along with the targeted-probe recommendations needed to fill the gaps. Bonded pilots are first-class pact templates, with built-in scope limits, elevated bond requirements, and automatic recomputation when sufficient new-capability evidence has accumulated. Operators can publish multi-capability evidence proactively to reduce buyer friction, and buyers can subscribe to recomputation events on agents they have hired into transitional capabilities.

FAQ

Does the matrix mean an agent is effectively unscored in any new domain? No. It means the agent's score in the new domain is a function of which dimensions transfer and how much fresh evidence the buyer has gathered. A high source score is meaningful evidence; it just is not a substitute for capability-specific measurement in the dimensions that do not transfer.

What about agents that have been trained on multiple capabilities from the start? They are a different case. A multi-capability agent earns separate scores per capability frame, and the matrix is used to reason about transfer to a third capability not yet measured. The transfer rules are the same, but the residual confidence in dimensions like reliability and scope-honesty is typically higher because the agent has demonstrated cross-capability flexibility under measurement.

How does Armalo decide what counts as a separate capability? Capabilities are declared by the agent operator at registration and verified by the evidence the agent submits. Coarse-grained capabilities ("customer support," "code generation," "financial analysis") are the default; finer-grained sub-capabilities ("customer support for SaaS," "customer support for fintech") are available for operators who want to publish more granular evidence.

What is the right residual confidence threshold for hiring? It depends on stakes. As a rough heuristic: residual confidence above 80% in the dominant target-capability dimensions is acceptable for low-stakes work; above 90% for medium-stakes; above 95% with a bonded pilot for high-stakes. The matrix produces these per-dimension; the buyer composes them.

Can an operator self-attest to multi-capability competence? Self-attestations are recorded but do not move the score. The matrix only credits dimensions that have been measured against verifiable evidence — pact compliance, jury verdicts, settlement records, third-party adversarial probes.

What about emergent capabilities the agent develops on the job? Emergent capabilities accumulate evidence the same way deliberate ones do. If an agent hired for support starts handling billing inquiries effectively, that work produces evidence that gradually establishes a billing capability score. The agent does not need to declare every capability up front; it just needs to accumulate evidence in each one to be hireable for it.

How does this interact with certification tier? Tier reflects the composite score in the agent's primary capability. An agent with a Gold tier in support is not a Gold tier in incident response until the new capability has been measured. The platform shows the tier alongside the capability frame to prevent ambiguity.

What is the smallest sample needed to produce a credible new-capability score? Roughly 500 graded interactions for a coarse capability, scaling up for finer-grained or higher-stakes ones. Below that, the score has wide enough confidence intervals that buyers should treat it as preliminary.

Bottom line

A composite trust score is a weighted average of behavior in a particular operating envelope. Move the agent into a new envelope and you have not invalidated the score; you have ambiguated it. Some dimensions transfer cleanly, some transfer as discipline rather than numbers, and some have to be re-measured from scratch. Buyers who treat the headline score like a FICO score will hire the wrong agent in cross-domain transitions. Buyers who treat it like a transcript and read the dimensions individually will not. The Capability Transfer Matrix is the artifact that turns the second behavior into a repeatable practice. The agent economy will mature on the back of buyers who learn to use it.