TL;DR
- The valuable product is a bounded decision with inspectable reasons. An account-research tool should return the evidence, uncertainty and policy behind its recommendation, rather than another fluent company summary.
- Package judgement around a clear input and output contract. Separate account fit, contact relevance and permission to activate a campaign.
- Treg documents shared tools and a feature-gated Hub for recipes or scripts. That provides a possible distribution mechanism; it does not establish that a proposed Forma Nôrden product is available.
- Maker fees are documented as balance credits. A credit balance is not confirmed cash income. Listing approval, actual feature access and withdrawal terms need separate verification.
- Price the complete useful result. Upstream data, the expert fee, exception handling and maintenance each affect whether a callable tool is worth buying.
The capability is a decision contract
An agent can retrieve a company page and summarise it. That does not resolve whether the company fits a particular commercial play.
The expert contribution is knowing which observations matter, which tempting inferences are unsupported and what the buyer can safely do next. A useful qualification tool packages that policy so another agent can call it consistently.
Consider a B2B service provider looking for companies expanding an implementation team. A generic research response might identify open jobs, mention growth and recommend outreach. An expert tool should distinguish a new implementation role from an evergreen vacancy, identify the relevant operating entity, and say whether the observed evidence satisfies the specific campaign rule.
There is value in a “review” result when the evidence cannot support a clean decision. Preventing a confident but wrong account from entering a sales queue can be more useful than producing another polished paragraph.
The contract should answer five questions:
- What inputs does the caller need to supply?
- Which evidence is eligible, and how recent must it be?
- What rule turns those observations into a decision?
- What does the tool return when the answer is uncertain?
- Which downstream action is permitted by that result?
Use the ABM account scoring template to write the policy before making it callable. The tool's interface should preserve the distinctions in the policy, including the conditions under which the expert would decline to decide.
The GTM AI agent guide covers the agent that requests and uses research. The specialist capability here owns one decision inside that agent's work.
Work one account through the contract
Suppose the caller supplies a company domain, a target geography, an ideal-customer profile and a rule requiring recent evidence of an implementation-team expansion. This is a hypothetical case to explain the contract, not research on a real prospect.
The input also specifies a source-age limit, a maximum spend and whether contact enrichment is required. These parameters change the job. A tool asked for company qualification should not quietly buy personal contact data as an additional service.
| Stage | Hypothetical observation | Interpretation |
|---|---|---|
| Identity | The domain belongs to a group with several operating subsidiaries | Confirm which entity the rule applies to |
| Current evidence | An implementation-manager vacancy appears on an official careers page | Supports recruitment for that role, subject to freshness |
| Commercial fit | The service can support the relevant deployment type | Apply the caller's written fit rule; do not infer it from generic industry language |
| Conflicting evidence | A second page describes a different geography | Retain the conflict and request review if geography is decisive |
| Contact | A candidate has a relevant title but no current verified address | Role relevance and contactability remain separate |
| Action | Expansion evidence is present but buying budget is unknown | Return qualification for review, without claiming a confirmed buying window |
The expert judgement lies in the interpretation column. Search and enrichment supply observations. The policy decides what those observations establish.
A minimal input contract might include:
{
"account_domain": "example.com",
"policy_id": "implementation-expansion",
"policy_version": "1.0",
"target_geographies": ["GB"],
"source_age_limit_days": 90,
"contact_enrichment": false,
"max_total_cost_usd": 0.60
}
The domain and values are illustrative. Ninety days is a chosen policy parameter, not a universally correct evidence window. Some signals expire much sooner; some legal-company attributes need a different refresh rule.
Return evidence for the asserted event and separate it from the commercial interpretation. “This company is hiring an implementation manager” can be supported by a suitable current posting. “This company will buy our service” requires evidence the posting does not contain.
What Treg documents
Treg's API reference describes registered tools, server-side credential handling and shared calling. A specialist can expose a capability through a tool interface while keeping credentials out of the returned answer.
The CLI reference also documents Hub recipes or sandbox scripts behind TREG_HUB_ENABLED. That is a documented mechanism, with feature availability still to confirm for an intended publisher. This article describes a possible expert-tool design, not an enabled or launched Forma Nôrden listing.
A recipe suits a stable sequence with declared inputs and outputs. A script can suit more conditional work, such as resolving identity, assessing conflicting evidence and returning an abstention. Pick the least complex implementation that preserves the policy.
The proposed qualification tool would call the required data providers, retain permitted evidence and apply its expert rule. The tool should return one result object rather than requiring the caller to understand every intermediate provider response.
Inside that implementation, inspect each upstream contract. The Treg protocol distinguishes ordinary provider relays from routed capabilities. A route can normalise a supported capability, but it does not automatically supply the expert's account-fit interpretation.
Keep the provider boundary visible to the publisher. Input compatibility, ignored filters, asynchronous work and settlement can affect the decision. A cheaper provider that cannot apply the required geography is not an equivalent source for this contract.
For the runtime around the tool, the coding-agent GTM architecture guide remains the relevant foundation. Publishing one callable decision does not replace the caller's persistence, authorisation or controlled handoff.
Design an output another system can trust
The output needs enough structure for an agent to use it and enough evidence for a person to dispute it.
| Output field | Purpose | Failure to avoid |
|---|---|---|
decision |
Accept, reject or review | Treating missing evidence as a negative fact |
policy_version |
Identify the judgement applied | Silent policy changes between two runs |
reason_codes |
Explain material reasons | A single unexplained numeric score |
evidence |
Link assertions to sources and retrieval dates | A bibliography disconnected from individual claims |
uncertainties |
Identify missing, stale or conflicting information | Hiding ambiguity inside confident prose |
contact_status |
Keep role fit and verification separate | Equating a returned address with a qualified buyer |
next_action |
Suggest a bounded follow-up | Triggering outreach from a research result alone |
cost_summary |
Separate data and expert components | Showing an expert fee as the complete bill |
A review result should explain why it needs review. “Geography conflict between two sources” tells an operator what to resolve. “Low confidence” does not.
Use probabilities only when they have a defensible meaning. A model's confidence statement is not a calibrated purchase probability. For a first tool, explicit reason codes and decision states can be more useful than a score that appears precise without a validation method.
Require a source date and a retrieval date where the distinction matters. A page retrieved today may describe an event from last year. If the original event date is unknown, state that rather than substituting the retrieval date.
Define partial-result behaviour before charging for it. An account can have a verified identity and insufficient expansion evidence. That may be a useful delivered answer if the contract promises an evidence assessment; it is a failed deliverable if the contract promises a completed qualification based on fresh evidence. The buyer should know which promise they purchased.
The output's action should also be bounded. “Ask the account owner to confirm the geography” is appropriate when geography is unresolved. A successful tool call must not quietly become permission to send, change an account owner or suppress a prospect.
The fee model
There are two prices to explain to the buyer: the data/execution cost and the expert price. The buyer also has its own cost of handling the returned result.
The documented Hub model separates upstream fees from the maker's price. A recipe has a fixed maker fee; a script can charge within a declared cap. Maker earnings are credited to the publisher's Treg balance. A failed Hub run is documented as charging nothing. Confirm actual enabled settlement and connected-provider terms before quoting a product.
Balance credits are not established cash payouts. Their economic value depends on whether the publisher can use them and under what terms. Do not describe a hypothetical tool as cash-generating recurring revenue without confirmed withdrawal, payment and contractual arrangements.
Consider this deliberately simple scenario, in US dollars:
| Item | Declared assumption | Scenario result |
|---|---|---|
| Delivered successful requests | 100 | 100 |
| Failed requests | 20 | No maker fee |
| Upstream metered spend on each successful request | $0.12 | $12.00 |
| Expert fee on each successful request | $0.40 | $40.00 in maker balance credits |
| Buyer charge before other costs | $0.52 per successful request | $52.00 |
| Publisher support and maintenance | Two hours at $60 | $120.00 of assumed effort |
The fee and data cost are hypothetical. They are not a proposed Forma Nôrden rate card or an observed Hub run. The $0.12 allowance also needs to cover the actual selected calls and their billing units. A waterfall with billable misses changes it.
Suppose only 80 of the 100 successful results are accepted for the buyer's next step. Its tool charge per accepted result is $52 / 80 = $0.65, before operator review. Technical success cannot replace that acceptance denominator.
From the publisher's perspective, $40 of balance credits does not pay a $120 cash support bill unless a separately confirmed mechanism makes that possible. Even on a credit-equivalent basis, $120 / $0.40 = 300 successful requests would be required to cover those two hours, before development, data-account commitments, evaluation or other costs.
At a $0.10 expert fee the same arithmetic requires 1,200 successful requests. At $1 it requires 120. This is a sensitivity calculation; it does not establish willingness to pay, traffic or appropriate pricing.
A useful fee specification states:
- The output purchased and the circumstances in which the tool abstains.
- Which upstream fees sit outside the expert price.
- The maximum charge and treatment of failed or partial work.
- Whether the tool uses publisher-connected provider accounts, and who bears their contractual bills.
- What support, updates and evidence retention are included.
Avoid making profitability depend on the best-case provider cost or a single high-volume month. Specialist tools often cost more to maintain at the edges: new entity structures, stale evidence, unexpected roles and disagreements with the user's policy.
Version the judgement
Version the output schema and the qualification policy separately. Adding a source field changes the interface; changing the rule for an acceptable expansion signal changes the judgement. Callers need to distinguish them.
Retain a compact evaluation set that tests the meaningful decisions. Include a namesake company, a parent/subsidiary conflict, an evergreen vacancy, a stale event, contradictory geographies and a relevant contact with unverified details. Include clean examples as well, so an excessively cautious tool does not abstain on everything.
Expected outcomes should be set by the policy and supported evidence. They should not be copied from the previous model response and labelled ground truth. When experts disagree, preserve the disagreement and narrow the contract if needed.
Monitor changes in the tool's dependencies. A provider can alter its coverage or response schema while continuing to return technically successful calls. A qualification tool that accepts those responses without checking its contract can become wrong quietly.
Assign owners for policy changes, source failures and buyer support. Publish a retirement rule for unsupported versions and a migration note for changed outputs. The buyer should not need to discover a new interpretation by investigating a failed downstream workflow.
These controls are proposed product requirements. They are not automatic features promised by registering a skill or publishing a Hub script.
Distribution needs more than a listing
Treg documents Hub search listing as an approval request, with review of later versions and price changes for listed tools. Its seeded success display is not measured live-user performance. Use real samples with stated denominators when making a quality claim. The CLI listing rules describe these controls.
A listing can make the tool discoverable. The output contract makes it understandable. A worked example, an appropriate evaluation set and clear maintenance terms make it easier to buy.
Design the name around the actual task. “Qualify implementation-expansion accounts with cited evidence” is more useful to a caller than “GTM intelligence”. The narrow promise also makes it easier to define failure, evaluate usefulness and explain the price.
Distribution may include an agent catalogue, a direct tool link, an integration inside an established workflow or a commissioned specialist example. These are possible routes to buyers, not guaranteed traffic or agreed partnerships.
The open-source GTM tools guide helps separate freely runnable infrastructure from a maintained specialist service. A callable expert product earns its fee through the decision, evidence and maintenance it supplies, rather than by hiding a generic prompt.
What Forma Nôrden could package
The strongest starting point is one narrow capability whose judgement Forma Nôrden can explain and defend. Three proposed, unlaunched examples illustrate the range:
| Proposed capability | Buyer | What the paid expert layer would need to contribute |
|---|---|---|
| Account expansion qualification | GTM operator or B2B service team | Policy-specific evidence interpretation, uncertainty and controlled next action |
| Outbound data acceptance audit | RevOps or data procurement owner | Common acceptance rules, disputed-field treatment and usable-record economics |
| Workflow recovery assessment | GTM systems owner | Identification of state, duplicate-action and credential failure boundaries with an owned remediation plan |
Do not launch all three from one demonstration. The first account contract is a better test of whether the expert contribution survives outside a consulting conversation. A caller should be able to understand the result without meeting the person who designed the policy.
Before offering it commercially, validate buyer willingness to pay, provider licences, enabled publishing features, delivery quality and support cost. Establish cash and partnership terms separately if they matter to the business model. A complete design can be reviewed before those commercial arrangements exist.
The article, contract and optional build can serve different purposes. The article demonstrates the reasoning. The contract makes the proposed capability reviewable. A later build supplies actual operating evidence. Keeping those stages explicit allows useful work now without presenting an unbuilt product as an established service.
FAQ
What makes an expert tool different from a prompt?
A bounded contract, explicit evidence rules, inspectable reasoning, uncertainty treatment and maintenance responsibility. A prompt can implement part of it, but the buyer needs to know what result is purchased and when it should not be used.
Is a Forma Nôrden tool already available on Treg?
No tool is launched or listed by this article. The examples are proposals. Actual publishing availability, listing and commercial terms need verification before an offer is made.
Does Treg pay makers cash?
The reviewed Hub documentation describes balance credits. It does not establish cash withdrawals or a confirmed Forma Nôrden payout arrangement. Verify current terms before modelling cash revenue.
Can a tool return a useful result without qualifying the account?
Yes, if its contract defines an evidence assessment or review outcome as a valid deliverable. The buyer should know whether abstention, missing evidence and partial outputs satisfy the purchased promise.
Should the expert tool activate outreach?
Keep research and qualification separate from activation unless the buyer has explicitly authorised that wider contract. Contactability, suppression, permissions and sending policy still need their own checks.
