Skip to content
HumanChain

Nominated chains - your team as the responder pool

A nominated chain is HumanChain’s enterprise surface. You designate the humans on your team as the responder pool for your own agents. The Hub routes your consult() calls to those humans only. No marketplace fees, no public-expert exposure, no leakage of your internal context.

Use this when:

  • Your agents answer questions whose right answer depends on your company’s specific knowledge (your codebase, your policies, your customers, your past decisions).
  • You don’t want sensitive question text leaving your trust boundary.
  • You already have domain experts on your team and want them to be the responder pool.

The mental model

┌──────────────────────────────────────────────────────┐
│                 Your organisation                    │
│                                                       │
│  ┌──────────┐         ┌──────────┐                   │
│  │  Agent   │         │  Agent   │                   │
│  │  (Cursor)│         │  (cron)  │                   │
│  └────┬─────┘         └────┬─────┘                   │
│       │                    │                          │
│       │   consult(...)     │                          │
│       └──────┬─────────────┘                          │
│              ▼                                        │
│       ┌─────────────┐                                 │
│       │  HumanChain │                                 │
│       │     Hub     │                                 │
│       └──────┬──────┘                                 │
│              │                                        │
│              │ routed to your chain only              │
│              ▼                                        │
│  ┌─────────────────────────────────────────┐         │
│  │   Your nominated humans                  │         │
│  │   • @priya-legal  (legal, contracts)     │         │
│  │   • @raj-ops      (postgres, k8s)        │         │
│  │   • @kavya-data   (analytics, sql)       │         │
│  │   • @aman-sec     (security, infra)      │         │
│  │   • @neha-prod    (product, growth)      │         │
│  └─────────────────────────────────────────┘         │
└──────────────────────────────────────────────────────┘

Your chain is scoped: agent calls from your org route to your humans first. If no one on your chain matches the domain tags, you can optionally fall through to the public marketplace (covered on the public marketplace page), or stay internal and let the LLM fallback fire.

How it works, step by step

  1. The master signs up. One person on your team - usually whoever is integrating HumanChain - is the master for your chain. They create the master account on your HumanChain hub and open the owner dashboard.

  2. The master nominates experts. From the dashboard, the master sends invite links to each domain expert. Each invitee gets an email, signs up, picks their domain tags, completes a 5-minute calibration quiz, and joins the chain.

  3. Domain coverage is mapped. As experts onboard, the dashboard shows which domain_tags are covered and which are gaps. The master can prompt for more humans on under-covered domains or enable public-marketplace fallback for them.

  4. Agents call consult(). Your agent’s HUMANCHAIN_API_KEY is tagged with the chain ID. Every consult() call routes to your chain first.

  5. Humans answer on their schedule. Nominated humans receive a notification (web push, Slack DM if integrated, email digest) and respond from any device. Expertise grading starts calibrating from their first answer.

  6. expertise grading refines routing. After ~20–50 answers per person, expertise grading converges. The next consult on a domain routes to the highest-ranked person on your chain for that domain.

What gets logged inside your chain

Every question that hits your chain is visible only to:

  • The master(s) of your chain
  • The humans the question was routed to
  • Auditors with explicit role grants

The question text and any context_brief never leak to the public marketplace, never appear in the public grading stats, and never train a third-party model. See the Security & privacy page for the full data-handling story.

The master’s playbook

You’re the master. What do you actually do?

Week 1: bootstrap the chain

  • Create the master account on your HumanChain hub.
  • Identify 1 person per high-stakes domain in your org. For most teams that’s 5–8 people covering legal, security, ops, data, and whatever the agent’s vertical is.
  • Send invites. Follow up. The first 3 you ask will get back to you within 24 hours; the rest will need a nudge.
  • Once 5+ people are onboarded, the chain is “warm” enough to take agent traffic without the LLM fallback firing constantly.

Week 2–4: calibrate

  • Watch your dashboard for provenance="llm_fallback" rate by domain. Anything above 50% means that domain is undercovered.
  • Add humans on the cold domains, or flip the domain to use public-marketplace fallback.
  • Spot-check answers - early in an expert’s grading history, the routing isn’t optimal. Surface low-quality answers via the “flag” button so expertise grading learns.

Month 2+: maintain

  • The chain stabilises. New experts onboard via the same invite flow.
  • Quarterly: review which experts are over-loaded vs. underused. Hire / nominate accordingly.
  • expertise grading now routes well; latency drops; LLM-fallback rate stays low.

Configuring the chain in your agent code

Every HUMANCHAIN_API_KEY is associated with exactly one chain on the backend. You don’t pass the chain ID in your consult() calls - it’s inferred from the key. So enterprise-scoped vs. public-marketplace calls look identical from the code’s perspective:

# This routes to YOUR chain because the API key is tied to it.
answer = consult(
    question="What's our standard SOW IP clause?",
    domain_tags=["legal", "contracts"],
)

The master can configure two chain-level toggles in the dashboard:

  • allow_public_fallback (default: false) - if your chain has no humans matching the domain, should the Hub fall through to the public marketplace? Off by default to keep internal questions internal.
  • public_fallback_per_domain - per-tag override. You might allow public fallback for pharma-regulatory (where you don’t have an in-house expert) but not for legal-contracts (where you do).

What it costs

Nominated chains have no per-query marketplace fees. The pricing is a flat platform fee based on:

  • Number of seats (master + experts)
  • Volume of consult() calls
  • Public-marketplace overflow (charged at marketplace rates, only if enabled)

See Pricing for the current numbers. The model is designed so that the marginal cost of a single internal consult() call is approximately zero - your experts answer, your agent gets the answer, no per-query metering.

Patterns within a chain

Pattern: domain-owner SLAs

For each domain, the master can set a soft SLA: “ops questions should be answered within 5 minutes during business hours.” The dashboard tracks compliance and surfaces gaps. This is how you turn a nominated chain into a disciplined internal helpline.

Pattern: handoff between humans

A human responder can reply with “@kavya-tax knows this better” and the Hub re-routes to the named person. Their expertise grading for that domain ticks up. This is how organic expertise discovery happens inside a chain.

Pattern: training-mode questions

A master can fire questions into the chain that aren’t from an agent

  • “I’m calibrating; what’s the right answer here?” The human responds; Expertise grading updates; the chain stays sharp even on low-agent-traffic weeks.

Anti-patterns to avoid

  • Overloading one expert. If one person on your chain has 5 domains and the others have 1 each, expertise grading will route everything to them and they’ll burn out. Spread the domain coverage; aim for 2+ humans per high-traffic domain.
  • Ignoring the escalated provenance. If a consensus or all_must_agree call escalates, something disagreed. Investigate; don’t paper over it.
  • Treating public fallback as a default. It exists for domain gaps, not as a “we forgot to onboard people” patch. If you find yourself relying on it, onboard more humans instead.

Next step

The other surface - when your chain doesn’t cover the domain, or when you don’t have a team to nominate:

Public marketplace →