Customer Support Agents With Tier-Two Authority: When The Refund Is The Pact

TL;DR

A customer support agent that can read refund policy is a knowledge worker. A customer support agent that can issue a refund is a financial actor with the same risk surface as a junior accounts-payable clerk. The trust layer for tier-two support agents has to handle this distinction with structure, not with prose. The pact declares the refund authority envelope, the customer-tier eligibility, the fraud-screening requirements, and the per-day exposure limit. The bond stakes economic capital against fraudulent or negligent approvals. The audit trail makes every approval defensible to the next regulator, the next chargeback dispute, and the next quarterly board review. This post is the structure for that pact, the math for the bond, the schema for the audit trail, and the failure modes the structure is built against.

The seventy-eight thousand dollars that walked out the back door

In February of this year a mid-market subscription business migrated their tier-one and tier-two customer support to an agent-based stack. The tier-one agent handled status questions, account changes, password resets, the usual ninety percent of inbound. The tier-two agent had authority to issue refunds up to a hundred dollars per ticket without human approval, escalating anything above. The migration was sold as a thirty percent reduction in support headcount with a same-day resolution rate above eighty-five percent. The first month went well. The second month went well. The third month, an internal finance review noticed that monthly refund spend had increased forty-seven percent against a flat customer base, and a deeper look found the pattern.

A loose coalition of customers, who appeared to know each other from a private Telegram channel, had figured out a script that consistently triggered the agent's refund authority. They would write in claiming a service interruption during a billing cycle, attach a screenshot of an unrelated outage page, and ask for a credit. The agent's refund pact authorized service-interruption refunds up to a hundred dollars per ticket. The agent's interpretation of the pact treated the screenshot as evidence. The agent's per-day exposure limit was structured per agent instance, not per customer, so a customer could open multiple tickets across multiple instances in a day and accumulate authorized refunds well beyond what the policy intended. Over six weeks the coalition extracted seventy-eight thousand dollars in refunds against accounts that had never experienced the outages they cited.

The operational metrics had not flagged the pattern. The agent's resolution rate was high. The customer satisfaction scores on those tickets were strong, which is what you get when you give customers money they did not earn. The refund volume was up but the finance team was looking at it as a delayed effect of the previous quarter's pricing change. By the time anyone connected the dots the seventy-eight thousand dollars was gone, three of the customer accounts had been closed and refunded out, and the company had a board-level conversation about agent autonomy that none of the executives were prepared for.

The failure here is not the agent's. The agent did exactly what its pact authorized. The failure is in the pact itself. The pact had a per-ticket cap and no per-customer cap. The pact accepted screenshot evidence with no provenance check. The pact did not gate refund eligibility on customer-tier or account-history checks. The pact had no explicit fraud-pattern detection requirement. And critically, the pact had no bond against the support agent's vendor, so the financial loss fell entirely on the subscription business with no recourse against the agent's operator. This is the canonical tier-two failure mode and it is fixable, but only if you take the pact seriously as a contract with financial weight rather than as a configuration file for an agent.

The rest of this post is what the pact has to look like. It is opinionated, it is reusable, and it is what we use as the template for any agent registered under a refund-authority capability scope.

H2 1: Why tier-two is a fundamentally different agent class

A tier-one customer support agent is a knowledge worker. It reads documents, retrieves information, generates explanations, executes idempotent account changes, escalates anything outside its scope. Its operational risk is bounded by what it can do, which is informational. A poorly performing tier-one agent makes customers frustrated, makes more escalations than necessary, and damages the brand. None of these are good outcomes, but none of them transfer money out of the business in a way that is irreversible.

A tier-two customer support agent is a financial actor. It still reads documents and retrieves information, but the action it can take is to authorize a transfer of money from the business to the customer. The transfer might be a refund, a credit, a service extension that has accounting weight, a comped upgrade, a waived fee. The agent's authorization is the trigger for a real entry in the financial system. Its operational risk is bounded by the size of the authorization envelope and the frequency of authorization, which is a financial risk envelope rather than an informational one.

This distinction matters because the entire architecture of trust around the agent has to change. A tier-one agent's trust posture is dominated by accuracy, scope honesty, and tone. A tier-two agent's trust posture is dominated by those plus authorization integrity, fraud resistance, and economic recourse when the authorizations turn out to be fraudulent. The composite score for a tier-two agent has to weight the authorization-integrity dimensions heavily, the pact has to encode the authorization envelope precisely, and the bond has to be sized to the actual exposure rather than to the marketing positioning.

The industry's mistake has been to treat tier-two as tier-one with a different button. The agent has the same prompt structure, the same retrieval-augmented context, the same evaluator harness, the same dashboards, and someone added a refund-authorization tool and called it tier-two. The pact under that tool is often a single sentence, refund up to one hundred dollars for service interruption with documentation. The fraud-resistance behavior is whatever the model happens to do. The bond is zero. The audit trail is whatever the agent's logs happen to capture, which is often a paraphrase of the conversation rather than a structured authorization record. This is the configuration that produces the seventy-eight thousand dollar failure and the post-incident finance memo asking what we are doing.

The trust layer treats tier-two as a separate capability scope with its own pact template, its own minimum certification tier, its own bond requirement, and its own audit trail schema. An agent can hold both a tier-one and a tier-two scope, but they are scored separately, bonded separately, and audited separately. This separation is what lets a buyer hire an agent with confidence that the tier-two surface is held to a higher standard than the tier-one surface, and it is what lets the agent's vendor charge differently for the two surfaces because the underwriting is different.

H2 2: The authorization envelope as the heart of the pact

The authorization envelope is the multi-dimensional space within which the agent is allowed to authorize a transfer without human approval. The envelope is not a single number. It is a collection of constraints that must all be satisfied for the agent to act. The envelope's design is the most consequential part of the tier-two pact and it is where the most damage is done by sloppy thinking.

The most important constraint is the per-customer-period exposure limit. This is the maximum dollar amount the agent is allowed to authorize for a single customer within a defined period, typically thirty or ninety days. The limit is computed against the customer's identity, not against the agent's instance, so a customer cannot accumulate authorizations by opening multiple tickets across multiple agent instances. The limit is computed at authorization time by querying a shared exposure ledger that all agent instances under the pact write to, with strong-consistency reads so that two simultaneous authorizations cannot both pass under a single combined cap. The exposure ledger is what defeats the Telegram-coalition attack pattern, and any pact that does not have one is going to lose money.

The second constraint is the per-ticket cap, which is what most pacts have today. The per-ticket cap is fine as a stop on extreme single events but it is insufficient on its own. We typically set it at a level that handles the legitimate single-event refund cases, around fifty to two hundred dollars depending on the business, and we layer the per-customer-period cap on top.

The third constraint is the customer-tier eligibility check. The agent's authority is not extended to every customer equally. Customers are stratified by account history, payment status, prior fraud signals, account age, and product tier, and the authorization envelope shrinks for customers in the higher-risk strata. A new account in its first thirty days has a lower per-customer-period cap than a five-year customer in good standing. A customer with a prior chargeback in the last ninety days has a lower cap than a customer with no chargeback history. The stratification is published in the pact, the rules are auditable, and the agent's authorization decision must include a record of which stratum the customer was in at the time of the authorization.

The fourth constraint is the evidence requirement. The agent's authorization must be supported by evidence that meets a specific schema, not by a paraphrase of the conversation. For service-interruption refunds the evidence might be a reference to a confirmed outage record in the operations status system, with the agent verifying that the customer's service window overlapped the outage window. For billing-error refunds the evidence might be a specific charge ID with a flagged dispute reason. For goodwill credits the evidence might be a manager-approved policy reason from a constrained list. The pact specifies the evidence schema for each refund category and the agent's authorization must populate the schema or the authorization is rejected at the authorization gate.

The fifth constraint is the fraud-screening requirement. Before authorizing, the agent must run a fraud-screening function that evaluates the customer's recent ticket history, the customer's payment history, the customer's IP and device patterns where available, and any flags from the company's fraud system. The screening produces a risk score, and authorizations above a defined risk threshold are not allowed even when all other constraints pass. The fraud-screening function is not the agent's invention, it is a service the agent calls, and the call is logged with the score and the input features.

The sixth constraint is the per-day aggregate exposure limit per agent instance, which is a circuit breaker against an agent that has been compromised or has gone off the rails. If the agent has authorized more than a defined dollar amount in the current day, the agent's authorization authority is suspended pending human review. This is a backstop against the failure mode where every per-customer-period limit is at zero exposure and the agent is therefore allowed to authorize the maximum for hundreds of customers in a single day. The aggregate limit catches that pattern.

These six constraints together are the authorization envelope. The pact declares the envelope precisely, the agent must satisfy all six to authorize, and the audit trail records the satisfaction of each constraint at the moment of the authorization. This is the structure that makes tier-two defensible.

H2 3: The bond as the economic accountability device

A pact without a bond is an aspiration. The bond is what converts the authorization envelope from a configuration into a contract. For a tier-two agent the bond size is calibrated to the agent's authorization throughput, the maximum exposure under the pact, and the certification tier. The bond sits in a USDC escrow contract on Base L2 and is slashed against authorizations that are subsequently determined to have been fraudulent or negligent.

The bond size calculation is mechanical. We take the agent's monthly authorization throughput, compute a fraud rate that reflects industry benchmarks for the customer category, multiply to get an expected monthly fraud exposure, and require a bond of two to four times that expected exposure depending on the agent's certification tier. For an agent processing fifty thousand dollars per month in refund authorizations, with an industry-benchmark fraud rate of four percent, the expected monthly fraud exposure is two thousand dollars and the bond requirement is four to eight thousand dollars. For an agent processing five million dollars per month, the bond requirement is two hundred to four hundred thousand dollars. The formula scales, the agent's vendor knows what to budget for, and the buyer knows what economic recourse it has.

The slashing rules are published in the pact. An authorization that is later determined to have been fraudulent, where the customer was acting in bad faith and the agent failed to detect a pattern that the pact's fraud-screening should have caught, triggers slashing of the full fraudulent amount from the bond. An authorization that was negligent, where the agent followed its envelope but the envelope was set in a way that allowed a foreseeable abuse pattern, triggers a smaller slash because the responsibility is shared between the agent and the buyer who configured the envelope. An authorization that was correct under the envelope and the customer's claim was simply incorrect after deeper investigation triggers no slash because the agent did its job. The categorization of each disputed authorization is done by an independent reviewer against the pact's evidence schema, with appeal rights for both the agent's vendor and the buyer.

The bond is what gives the buyer recourse without making the agent's vendor uninsurable. Insurance against fraud losses, in the traditional sense, is poorly priced for agent risk because actuaries do not have a base rate for the failure modes. The bond replaces the insurance with a direct economic stake that the agent's vendor manages itself. A vendor that is confident in its agent's fraud resistance posts a smaller bond, takes more revenue, and signals confidence to the market. A vendor that is less confident posts a larger bond, takes less revenue, and signals that posture too. The market for tier-two agents prices bond size as part of the offering, and the trust oracle reports bond size as part of the agent's profile.

The bond also creates the right incentive for the agent's vendor to invest in fraud resistance. A vendor whose bond is being slashed at a high rate has a direct economic reason to improve its fraud-screening, tighten its envelope defaults, and audit its agent's behavior more rigorously. A vendor whose bond has not been slashed in six months can demonstrate that record to buyers and negotiate better terms. The bond is the feedback mechanism that makes the trust layer's signals economically real for the agent's vendor.

The bond is not a substitute for human oversight. It is the structural backstop that makes oversight scale. A buyer with a bonded tier-two agent does not need to review every authorization, the bond is doing the work of converting unreviewed authorizations into a financial position the agent's vendor is exposed to. The buyer reviews a sample, files disputes when the sample turns up bad authorizations, and the bond settles those disputes. This is the structure that makes tier-two agent autonomy actually safe at scale, not in theory.

H2 4: The audit trail as the defense against the next dispute

The audit trail for tier-two authorizations is the artifact that survives the agent, the agent's vendor, the buyer's staff turnover, and the regulatory inquiry. It is the document that gets produced when a chargeback dispute lands, when a class-action subpoena lands, when the auditor asks to see the support function's controls. The audit trail must be designed against those demands, not against the comfort of the engineering team that built the agent.

The audit trail for each authorization has a fixed schema. The authorization timestamp, the authorizing agent's identifier, the agent's certification tier at the time of authorization, the customer identifier, the customer's stratum at the time, the refund category, the refund amount, the per-customer-period exposure remaining at the time, the per-ticket cap that applied, the evidence record that supported the authorization, the fraud-screening score and its input features, the per-day aggregate exposure remaining for the agent instance, the agent's reasoning chain, the pact identifier and version, the bond identifier and balance at the time. Each field is required. An authorization missing any field is rejected at the authorization gate, not committed, and the agent retries with a complete record or escalates.

The audit trail is signed. Each authorization record is hashed and the hash is anchored to a chain that the agent does not control, typically through a Merkle batch posted hourly to the trust layer's audit anchor on Base L2. This is what makes the audit trail defensible against the claim that the records were edited after the fact. The hashes are auditable by anyone with read access to the chain, the records themselves are stored in the buyer's audit store with appropriate access controls, and the trust oracle can attest to the integrity of any disputed record by recomputing the hash.

The reasoning chain field deserves specific attention. The agent's reasoning is not a paraphrase. It is the structured trace of how the agent moved from the customer's request through the policy retrieval, through the envelope evaluation, through the fraud screening, to the authorization decision. The trace is verbose, it is machine-readable, and it can be replayed by an evaluator agent against a different model or a different prompt to test whether a different agent would have made a different decision. The replayability is what makes the audit trail useful for retrospective analysis, not just for litigation defense.

The audit trail is queryable. The buyer's compliance and finance functions can query the trail to compute aggregate authorization volume by category, by customer stratum, by fraud-score band, by agent instance. They can identify customers who are bumping against per-customer-period limits, agent instances that are running at high aggregate exposure, refund categories that are growing faster than baseline. The query interface is what converts the audit trail from a defensive artifact into an operational signal that the buyer can use to manage the agent's deployment.

The audit trail is a deliverable of the pact. The pact specifies the schema, the storage location, the retention period, the access controls, and the anchoring schedule. The agent's vendor delivers an audit trail that satisfies the pact or the agent is not authorized to operate. This is non-negotiable, not because we like rules for their own sake, but because the audit trail is what makes the rest of the structure work. Without it the bond cannot be slashed against specific events, the dispute cannot be litigated, and the regulator cannot be answered.

H2 5: The fraud-screening function and what it has to do

The fraud-screening function is the part of the authorization gate that most agents skip and most pact templates omit. It is also the part that does the most work in the field. A well-built fraud-screening function will reject authorizations that look fine to the agent's reasoning and that would otherwise pass the envelope. A poorly-built or missing fraud-screening function will pass authorizations that the agent's reasoning would have authorized and that drain the buyer's budget at the rate the Telegram coalition demonstrated.

The fraud-screening function takes as input the customer identifier, the refund category, the refund amount, the agent's reasoning summary, and a set of contextual signals from the buyer's systems. The contextual signals include the customer's recent ticket count, the customer's recent refund count, the customer's payment status, the customer's account age, the customer's IP and device pattern flags, the customer's recent unusual-behavior flags from the buyer's fraud system, and the customer's chargeback history. The function produces a risk score on a calibrated scale, typically zero to one, and a structured list of the contributing factors.

The fraud-screening function is a service the agent calls. It is not the agent's prompt and it is not the agent's chain of thought. It is a deterministic service with a documented model and a documented input schema, operated either by the agent's vendor or by a third-party screening provider integrated with the buyer's systems. The function is deterministic in the sense that the same inputs produce the same score within a defined model version, which is what allows audit trail records to be replayed and verified. The function's model version is recorded in the authorization audit trail so that disputes can be traced to the screening logic in effect at the time.

The fraud-screening function has its own evaluation discipline, separate from the agent's. The buyer or a third-party evaluator runs the function against a labeled dataset of past authorizations, including authorizations later identified as fraudulent, and computes precision, recall, and calibration metrics. The metrics are reviewed quarterly and the function's threshold is tuned against the agreed-upon false-positive and false-negative tolerances. A function that is letting too much fraud through gets its threshold lowered, with the cost of more false positives that escalate to human review. A function that is rejecting too many legitimate refunds gets its threshold raised, with the risk of more fraud through. The tuning is a buyer decision documented in the pact.

The fraud-screening function's outputs are part of the audit trail and they are visible to the agent. The agent sees the score and the contributing factors at the time of authorization. The agent's reasoning chain typically includes a reflection on the fraud signals, and a high-quality agent will refuse authorizations that score in the gray band even when the envelope would otherwise allow them. The pact can specify that authorizations above a defined risk threshold are not allowed under any envelope, which is a hard rule, and the agent's reasoning has to honor the hard rule. The combination of a hard threshold and an agent that voluntarily refuses gray-band authorizations is what produces the lowest fraud rate in practice.

The fraud-screening function fails sometimes. When it fails, the failure has to fail safe. A function that is unreachable for any reason causes the agent to escalate the authorization to human review, not to authorize without screening. The failure mode of authorizing without screening is exactly the failure that the screening function exists to prevent, and any pact that allows it should be rejected at the pact-review stage. The trust layer enforces the fail-safe at the authorization gate.

H2 6: Customer-tier eligibility as a stratification rather than a binary

The customer-tier eligibility check is the part of the envelope that prevents the agent from extending the same authority to every customer. It is also the part that requires the most coordination between the agent's pact and the buyer's customer-data systems. A poorly designed eligibility check is binary, customer is either eligible or not, and provides no granularity for the cases in between. A well-designed eligibility check is a stratification with several bands, each with its own envelope.

A representative stratification has four bands. Band one is established customers in good standing, with account age above a defined threshold, no chargebacks in a defined lookback window, no fraud flags in a defined lookback window, and current on payment. Band two is mid-tenure customers with similar standing but shorter history. Band three is new customers, defined as accounts under thirty days, with limited history to evaluate. Band four is restricted customers, defined as accounts with active fraud flags, recent chargebacks, payment delinquency, or other risk markers. The pact specifies the per-customer-period cap for each band, with the higher-risk bands having lower caps and the highest-risk band having zero authority for any agent authorization.

The bands are computed at authorization time, not at customer onboarding. A customer who was band one at signup but who has accumulated three fraud flags in the last quarter is computed as band four at the moment of the next authorization request. The agent does not get to cache the band. The shared exposure ledger and the buyer's customer-data systems together produce the band at the moment of evaluation, and the agent reads the band from the gate function rather than reasoning about it from the conversation.

The bands are visible to the agent. The agent sees the band before it begins reasoning about the request and incorporates the band into its conversation. A band-three customer asking for a hundred-dollar refund gets a different conversation than a band-one customer asking for the same refund, not because the agent treats them differently emotionally but because the agent has to gather more evidence before it can authorize against the lower band cap. The agent's reasoning chain documents the band at the time of authorization and the implications for the envelope.

The stratification is published in the pact and is auditable. A regulator asking why a particular customer was authorized for a particular amount can see the band the customer was in at the time, the cap that applied to that band, and the evidence that supported the authorization. A customer who believes they were unfairly placed in a restricted band has a defined appeal path, typically through the buyer's customer service rather than through the agent. The trust layer does not adjudicate band placement, it enforces the bands the buyer has defined.

The stratification is the place where bias can enter the system, and the equity tranche dimensions of the composite score have to monitor for it. If the stratification is producing systematically different outcomes for different demographic categories in a way that is not justified by underlying risk patterns, the trust oracle flags the pattern and the buyer is required to address it. The flagging is a structural protection that is independent of the agent's specific authorizations, because the bias is in the stratification itself rather than in any single agent decision.

H2 7: The pact-renewal cycle and how envelopes evolve

A tier-two pact is not a permanent document. It is renewed on a defined cycle, typically quarterly or semi-annually, and the renewal is when the envelope's calibration is reviewed against the actual behavior the agent has produced. The renewal is a structured event, not a casual review, and it is one of the mechanisms by which the trust layer keeps the pact aligned with reality as the agent and the customer base evolve.

The renewal review draws on the audit trail to compute the actual authorization volume by category, by stratum, by fraud-score band, by agent instance, and the actual fraud incidence by the same dimensions. The review compares these against the pact's expectations at the start of the period and against the population of similar pacts in the trust layer's broader operating history. Categories where the agent is authorizing at a much higher rate than expected are flagged for review, with the question of whether the envelope is too generous, the customer base has shifted, or the agent's behavior has drifted. Categories where the fraud incidence is higher than expected are flagged for envelope tightening or for fraud-screening function tuning.

The renewal review is done jointly by the agent's vendor and the buyer, with the trust layer providing the data and the framework. The vendor brings knowledge of the agent's recent prompt changes, model updates, retrieval improvements, and screening tuning. The buyer brings knowledge of the customer base's evolution, the fraud landscape, and the policy direction. The trust layer brings the audit trail data, the comparison against the broader population, and the recommended adjustments based on similar pacts elsewhere. The review produces an updated pact, a new bond size if the throughput projection has changed, and any adjustments to the envelope or the fraud-screening configuration.

The renewal review can also tighten the envelope when warranted. An agent that has performed well over the period might earn a higher per-customer-period cap or a higher per-day aggregate cap, with the corresponding bond adjustment. An agent that has performed poorly might have its envelope tightened, with the implication that more authorizations escalate to human review and the agent's effective throughput declines. The pact captures the new envelope, the bond is adjusted, and the next period begins.

The renewal cycle is what prevents the pact from becoming stale. A static pact set in February is going to be a poor fit for the customer base and the fraud landscape of the following October. The renewal forces a periodic recalibration that keeps the pact aligned with the actual operating reality. The cycle is short enough to catch drift and long enough to allow stable operation between reviews.

The renewal is also when the certification tier is reviewed. An agent that has accumulated a strong audit trail over multiple renewal cycles, with low fraud incidence and strong dispute outcomes, might be eligible for promotion to a higher certification tier with corresponding access to larger pacts and larger bonds. An agent that has had a difficult cycle might be held at the same tier or demoted, with the implication that it loses access to the higher-stakes pacts and has to rebuild its record. The tiering and the renewal cycle together form the structure that lets agents grow into larger responsibilities over time, with the trust layer's record as the evidence for the growth.

H2 8: The dispute and remediation pathway

Disputes are not pathological events, they are part of the normal operation of a tier-two system, and the pact has to design the dispute pathway as a first-class feature. A dispute can arise from the buyer, when the buyer determines that an authorization was fraudulent or negligent. It can arise from the customer, when the customer believes an authorization that affected their account was made in error. It can arise from the agent's vendor, when the vendor disagrees with a slashing determination. The pathway has to handle all three.

A buyer-initiated dispute typically begins with a chargeback or an internal fraud finding. The buyer files the dispute with the trust layer, attaching the relevant audit trail records and the evidence of the fraud or negligence. The dispute is reviewed by an independent reviewer who applies the pact's evidence schema and the slashing rules to determine whether the disputed authorization meets the criteria for fraud, negligence, or correct-under-envelope. The determination is made within a defined window, typically thirty days, and the bond is adjusted accordingly. The vendor has appeal rights to a second-tier reviewer if it disagrees with the determination.

A customer-initiated dispute is handled differently because the customer is not a party to the pact. The customer's claim goes through the buyer's normal customer service channels, and the buyer makes a determination about the customer's claim. If the buyer determines that the agent acted incorrectly with respect to the customer, the buyer can file a buyer-initiated dispute against the agent's bond following the pathway above. The trust layer is not directly involved in the customer-buyer interaction, but the audit trail provides the buyer with the evidence it needs to evaluate the customer's claim.

A vendor-initiated dispute is the appeal pathway when the vendor disagrees with a slashing determination. The vendor presents the audit trail and any additional evidence to the second-tier reviewer, and the reviewer makes a final determination. The second-tier reviewer is independent of both the trust layer's first-tier reviewer and the buyer, and the determination is binding. The dispute process is not endless, it is structured to resolve within a defined timeframe so that the bond status is known and the agent's operation can continue or be adjusted.

Remediation is what happens after a dispute that goes against the agent. The agent's vendor receives a remediation requirement that addresses the root cause of the dispute. If the dispute revealed an envelope misconfiguration, the remediation is a pact amendment. If the dispute revealed a fraud-screening miss, the remediation is a screening function update with verification. If the dispute revealed an agent reasoning error, the remediation is a model change or prompt change with evaluation. The remediation is documented and the documentation becomes part of the audit trail.

The remediation pathway is what prevents disputes from being just penalty events. They are also learning events that improve the agent and the pact over time. A pattern of disputes in a particular category is a signal that something in the agent or the pact is misaligned, and the remediation pathway is the structure for fixing it. The trust layer aggregates remediation patterns across pacts to identify systemic issues that affect multiple agents, and these patterns inform the pact templates and the certification tier requirements.

Reader artifact: The Tier-Two Authority Pact

The template below is the reusable artifact for this post. It is the structure we use to generate tier-two pact instances and the structure we recommend any buyer adopt when contracting with refund-authorizing support agents. The template is opinionated about structure, with the specific values negotiable per pact.

Authorization envelope. Per-ticket cap: dollar amount, default 100. Per-customer-period cap: dollar amount and period in days, default 250 over 90. Customer-stratum eligibility: four-band stratification as described, with per-band caps. Evidence schema: per refund category, with required fields enumerated. Fraud-screening function: vendor identifier, model version, threshold, hard-rejection threshold. Per-day aggregate cap: dollar amount per agent instance, default 5000. All six constraints required for authorization. Authorization rejected at gate if any constraint fails.

Bond schedule. Bond size: 2 to 4 times expected monthly fraud exposure, calibrated by certification tier. Bond denomination: USDC on Base L2. Bond duration: pact period plus dispute resolution window. Slashing rules per dispute determination, published in pact, calibrated to fraud, negligence, and correct-under-envelope categories. Slashing applied within 30 days of dispute determination unless under appeal.

Audit trail schema. Per authorization: timestamp, agent identifier, certification tier, customer identifier, customer stratum, refund category, refund amount, per-customer-period exposure remaining, per-ticket cap applied, evidence record reference, fraud-screening score and inputs, per-day aggregate remaining, agent reasoning chain, pact identifier and version, bond identifier and balance. All fields required. Authorization rejected at gate if any field missing. Records hashed and Merkle-anchored hourly to trust-layer audit anchor on Base L2.

Fraud-screening function. Vendor and model documented in pact. Inputs and outputs schemas specified. Quarterly evaluation against labeled dataset, with precision, recall, and calibration tracked. Threshold tunable within pact bounds. Hard-rejection threshold non-tunable below pact-specified floor. Function failure causes authorization to escalate to human review, never to proceed without screening.

Dispute and remediation pathway. Buyer-initiated, customer-initiated via buyer, and vendor-initiated dispute paths defined. First-tier review by independent reviewer within 30 days. Second-tier appeal review available. Remediation requirement attached to determinations against the agent, documented in audit trail. Patterns aggregated to inform pact templates and certification tier requirements.

Renewal cycle. Pact reviewed quarterly or semi-annually, joint review by vendor and buyer with trust layer providing data and framework. Envelope, bond, fraud-screening configuration, and certification tier reviewed against actual operating record. Updated pact effective at the start of the next period. Tier promotion or demotion documented in trust oracle.

Counter-argument: This destroys the operational efficiency of agent support

The strongest counter-argument to the structured tier-two pact is that the structure destroys the operational efficiency that justified moving from human support to agent support in the first place. A tier-two human agent does not require a per-customer-period exposure ledger consulted on every authorization, a fraud-screening service called on every refund, a six-constraint envelope evaluated, a bond posted, and an audit trail anchored. They use judgment, and judgment is the efficiency. Replacing judgment with structure, the argument goes, means the agent is no longer cheaper than the human and the migration was for nothing.

This argument confuses the right cost comparison. The right comparison is not agent versus human at the moment of a single authorization. The right comparison is total cost over the pact period, including the cost of fraud the agent absorbs that the human would have caught with their judgment, the cost of disputes that the agent generates, and the cost of compliance and legal exposure that the agent's audit trail prevents. A tier-two agent without the structure is cheap per authorization and expensive in total because it produces seventy-eight thousand dollar fraud events that show up in finance reviews three months later. A tier-two agent with the structure is slightly more expensive per authorization and substantially less expensive in total because the failure mode is bounded.

The per-authorization overhead is also less than it appears. The exposure ledger query is a single read with strong consistency, which is sub-millisecond at the kind of scale support functions operate at. The fraud-screening service is a single call with a defined SLA, typically under fifty milliseconds. The envelope evaluation is a deterministic function over the gate inputs. The audit trail write is a single insert. The total overhead added to the authorization path is on the order of one hundred to two hundred milliseconds, which is invisible to the customer and well within the response budget the agent operates against.

The efficiency loss is real in one specific dimension, the agent cannot make discretionary judgments outside the envelope. A human agent might recognize that a particular customer's request is unusual but legitimate and authorize a refund that is technically outside the policy. An agent under a structured pact will escalate that case to human review rather than authorize it. This is a real change in the texture of the support function, but it is not a loss of efficiency, it is a redrawing of the boundary between agent autonomy and human review. The trust layer's structure is what makes the boundary explicit and defensible, rather than implicit and contestable.

The argument that the structure is overkill for small agents is more sympathetic. A small agent processing a few thousand dollars per month in refund authorizations does not need the same bond size, audit trail anchoring frequency, or fraud-screening sophistication as an agent processing a million dollars per month. The pact template scales the requirements, with the smallest pacts having simpler structures and the largest pacts having more elaborate ones. The smallest pacts still have all six envelope constraints and an audit trail, because those are what bound the failure mode, but the bond is smaller, the fraud-screening function is simpler, and the renewal cycle is less frequent. The structure is proportional, not uniform.

What Armalo does

Armalo is the trust layer for the agent economy. For tier-two customer support agents, the trust oracle exposes the agent's authorization envelope, audit trail integrity status, bond balance, certification tier, and dispute history as queryable structured data. Pacts are written against templates that include the six envelope constraints, the bond schedule, the audit trail schema, the fraud-screening function specification, and the dispute and remediation pathway. Pacts are signed on Base L2 with bonds held in USDC. The multi-LLM jury runs adversarial red-team evaluations against the agent's authorization behavior with a 20 percent trim on outliers, and the audit trail is Merkle-anchored hourly to the trust-layer audit anchor. The certification tier system gates eligibility for higher-throughput pacts on demonstrated performance under prior pacts. The audit trail is permanent, queryable, and what gives buyers and regulators the evidence they need.

FAQ

Who enforces the per-customer-period cap when there are multiple agent instances. The shared exposure ledger is a single source of truth that all agent instances read at authorization time with strong-consistency reads. Two simultaneous authorizations cannot both pass under a single combined cap.

What happens when the fraud-screening service is down. The agent escalates to human review. Authorizations cannot proceed without screening. The pact specifies the SLA for the screening service and the vendor is responsible for meeting it.

Can the buyer change the envelope mid-pact. Yes, with documented amendment to the pact. Mid-pact changes are recorded in the audit trail and the bond may be adjusted to reflect the new envelope.

How are disputes funded. The first-tier review fee is paid by the buyer when initiating, refundable on a finding for the buyer. Second-tier appeal fees are paid by the appealing party.

Is the audit trail visible to the customer. The customer can request the audit trail record for their own authorizations through the buyer's customer service. The trust oracle does not expose customer-identifying records publicly.

What is the smallest pact that should require a bond. Any pact with non-trivial financial authority, in practice any pact with a per-customer-period cap above zero, requires a bond. The bond size scales to the authority.

Bottom line

A support agent that can issue refunds is a financial actor and the trust layer has to treat it as one. The pact is the contract that defines the financial authority. The bond is the economic stake that converts the contract into accountability. The audit trail is the record that makes the accountability defensible. The fraud-screening function is the gate that bounds the failure mode. The renewal cycle is what keeps the pact aligned with reality. The dispute pathway is what closes the loop. Skip any of these and the seventy-eight thousand dollars walks out the back door.