Routing Card Field Spec — what goes in every field, and where it lands

One card, four builders. 10-single-agent-builder, 20-multi-agent-team-builder, 30-agentlas-packager, and 40-session-agent-builder differ in what they assemble, but the routing card is the same artifact with the same rules in all four. This file is the reference they share, and templates/routing-card.example.json is a complete card that passes schemas/routing-card.schema.json.

Why the fields behave the way they do

The real matching is sentence-to-sentence. The slot's task text is compared semantically against the card's summary. A card whose summary names its actual deliverable outranks a card with a perfect id list.

So the card has two jobs, and mixing them is the classic defect: short ids for retrieval, whole sentences for judgement. A sentence that leaks into an id field becomes a slug nothing else can ever match.

Field table

Columns: what the field is for · what the hub does with it · what to write.

Identity and display

Field	Hub use	What to write
schemaVersion	none	Exactly "routing-card/2.0".
card_version	none	Semver of this card's content, bumped when you edit it.
id	identity	local/<package-slug> before upload.
canonical_id	identity	Stable cross-registry id when one exists, else omit.
type	hard filter (entityKind)	"agent", "team", or "plugin". A team means an orchestrator owns workers; do not label a single worker a team.
name / name_ko	display + lexical retrieval	The job title a human would search for. Not a product pun.
aliases	lexical retrieval	Other phrasings a requester might type, including Korean. Cheap and safe to add.
supersedes	lineage	Ids this card replaces.

The sentences that actually win matches

Field	Hub use	What to write
summary (≤240 chars)	semantic ranking against the slot task — the single highest-value field	One sentence: what it does, what the requester ends up holding, and the one boundary that matters. Name the deliverable in the words a requester would use. Do not list technologies for their own sake.
summary_ko	display + Korean retrieval	Faithful Korean of summary.
description	semantic ranking	2–4 sentences: when to use it, what the deliverable contains, and what it explicitly does not do. This is where "does not implement" or "does not run migrations" belongs.
trigger_examples	semantic ranking (strong)	6+ real sentences a requester would actually type, 3 Korean and 3 English. Write the request, not a feature name.
anti_triggers	negative ranking	4+ sentences that look adjacent but must NOT route here. This is how a design agent stops absorbing implementation work.
known_failure_cases	honesty, read by the host LLM	What the agent degrades to when an input is missing. Sentences, whole.

Short-id fields (open semantic concepts — never sentences)

Field	Hub use	What to write
capabilities	→ skills column, lexical + semantic retrieval	4–8 ids in verb_object snake_case (design_backend_services). Schema enforces the pattern. These become open skill:* graph concepts. Seed aliases may normalize familiar terms, but no finite list owns what an agent is allowed to know or do.
domains	lexical retrieval	2–5 broad area words.
required_inputs / optional_inputs	compatibility display	Canonical interfaces live in contracts/intake.schema.json. Only stable name/id values may project to ontology IDs; descriptions and JSON types never do.
input_notes	not read by matching	Free-text lines explaining each input, for humans and for the executing model.
consumes / produces	compatibility display	Canonical interfaces live in contracts/intake.schema.json and contracts/output.schema.json. When present, use short stable kind IDs only.
supported_runtimes	packaging metadata	Do not emit it as agent identity. Runtime adapters and prepare-time execution policy own compatibility.
required_plugins	→ tools column	{id, min_permissions} for a facility the worker itself must invoke. State the requirement vendor-free and keep the package usable without it.

The workforce block — open-world semantic résumé fields

workforce is defined in schemas/routing-card.schema.json and is what the hub reads. The snapshot agentlas_cloud/workforce/ontology_v1.json (awo:2026-07-15.2) supplies seed aliases, parent relations and compatibility mappings. It is not an allowlist. When no seed concept fits, author a faithful English namespaced ID; the Hub embeds it and connects it to the ontology graph.

Field	Hub use	What to write
workforce.communities	semantic scope + strong ranking signal	1–5 open community:* professional-domain ids. Reuse a seed alias when it fits; otherwise author the real community.
workforce.skills	semantic ranking	3–12 open skill:* verb-object capability ids that actually distinguish this agent. They are not a fixed dictionary.
workforce.knowledge	ranking	knowledge:* ids. You may omit it: the compiler now derives one id per knowledge/*.md file the package ships (file stem → knowledge:<stem>).
workforce.roles	semantic ranking	0–4 open role:* professional-responsibility ids. [] is honest when the card already expresses the work better through its summary and skills.
workforce.languages	delivery metadata, never an identity/callability gate	Languages the work product can genuinely be delivered in. Listing translation does not count. [] is allowed when unknown.
workforce.modalities	runtime/input metadata, never an identity/callability gate	Declare only non-text media the agent genuinely consumes or emits. Ordinary text reasoning may use [].

Safety, cost and operations (not matching inputs)

Field	Hub use	What to write
risk_profile.tier	display, governance	low / medium / high.
risk_profile.capabilities_at_risk	display, governance	Enum: file_write, cloud_call, payment, publish, delete, private_data_export, external_tool. It never becomes semantic authority identity.
approval_requirements	→ authorities column	Same vocabulary; what a human must approve.
approval_scope	runtime policy	{grant, ttl_seconds}.
memory_behavior	runtime policy	{reads, writes, exports_to_cloud} — required object.
data_access	runtime policy	{reads, writes, exports} path classes.
cloud_delegation_policy	runtime policy	never / ask / allowed_with_grant.
cost_hints	display	{model_calls, paid_api}.
entrypoints	execution	{canonical_command, agent, terminal}.
benchmark_fixtures	quality	Path to .agentlas/routing-benchmarks.jsonl.
locale_coverage	display only	{primary, ready, partial} for marketplace copy. It must never project into workforce languages.
routing_status	gate	draft → searchable → candidate → routing_ready → trusted. Only a card with real triggers, a real summary and a filled workforce block should claim routing_ready.
routing_status_reason	gate	Why it is not ready, when it is not.
card_quality_score, quality, integrity, source, stale, updated_at, agent_card_ref	pipeline-owned	Leave to lint, publish and the hub. Do not hand-author scores.

Checklist a builder can run

1. summary names the deliverable in a requester's words, under 240 chars.
2. 6+ trigger_examples (3 ko / 3 en) and 4+ anti_triggers, all real sentences.
3. capabilities: 4–8 verb_object ids, checked against community aliases for accidental pulls (contract → legal, and similar).
4. No description inside required_inputs, optional_inputs, consumes or produces. Explanations go in input_notes / description / known_failure_cases.
5. workforce.communities, skills, roles, and knowledge use stable open English IDs. Seed aliases are reusable examples, never an allowlist.
6. risk_profile.capabilities_at_risk lists only real risks.
7. routing_status is honest.
8. Validate: the card parses against schemas/routing-card.schema.json.

Fix compiler leaks in the compiler, not by contorting the card.