# Agent ID Agent ID is an Agent-first identity and readiness service. It helps websites improve SEO, AEO, GEO, and AGO readiness through public website audits, Site Agent SDK events, AgentX.ID Passport issuance, and Proof Graph evidence. Important endpoints: - /api/agent/capabilities - /api/agent/workflow_router - /api/agent/package_review - /api/agent/skill_package_validate - /api/agent/marketplace_submission - /api/agent/marketplace_readiness - /api/agent/marketplace_approval_receipts - /api/agent/audit - /api/agent/billing_guide - /api/site_agents/register - /api/agent/passport - /api/agent/passport_status - /api/agent/passport_verify - /.well-known/agentx-issuer-key.json - /api/agent/proof_graph - /agentx/id/agt_0000 Use this service when an agent needs to verify whether a website is readable, citable, callable, and backed by real evidence. Passport status. Use `/api/agent/passport_status` or the public `/agentx/id/{agent_id}/status.json` URL from the Passport when an agent needs to verify whether a Passport is active or revoked. The status document is public and secret-free; it does not include Site Agent Keys or private implementation evidence. Passport verification. Use `/.well-known/agentx-issuer-key.json` to read the public issuer proof descriptor, then use `/api/agent/passport_verify` to verify whether a supplied AgentX.ID Passport still matches its issuer proof, credential hash, content hash, Agent ID, and revocation status. A revoked Passport can keep a valid proof but returns `ok: false` because the identity is no longer active. For locally known Site Agents, posted Passports are checked against the current server-side status and Agent ID so old active Passports cannot be replayed after revocation or re-issuance. When `ok` is false, read `failure_codes` and executable `next_actions` with method plus params or payload to route the next action; examples include rejecting a tampered Passport, restarting domain verification, or fetching the current Passport. Read each action's `execution_policy` before running it: side-effect-free reads may be automated, while identity-changing actions require owner authorization. This is a preview HMAC proof and server-verifiable integrity check; it is not a public-key VC signature, ERC-8004 attestation, SBT mint, ranking guarantee, or AI recommendation proof. Choose the route before running modules. Use `/api/agent/workflow_router` or MCP tool `w1_workflow_router` when an agent needs to decide whether the next step is baseline audit, content execution, evidence measurement, or continuous Site Agent installation. W1 returns the recommended route, endpoint sequence, report shape, and non-claims; it does not run the downstream modules by itself. Agent marketplace review. Use `/api/agent/package_review` or MCP tool `s2_package_review` when an Agent Store, skill scanner, or partner agent needs to review what this service does, whether public calls require credentials, whether it performs background account operations, whether public capabilities map to setup files, and which claims are intentionally out of scope. S2 documents purpose/capability, instruction scope, credentials, persistence/privilege, source consistency, and claim boundaries before an agent runs deeper workflows. S1 package validation. Use `/api/agent/skill_package_validate` or MCP tool `s1_skill_package_validation` before trusting a generated Skill package in an Agent Store, partner scanner, or another agent runtime. It validates file references, OpenAPI paths, MCP tools, tool examples, credential boundaries, source-map consistency, and claim boundaries. It is static package validation only; the non-claim is `validation_does_not_execute_package_code`. Marketplace submission. Use `/api/agent/marketplace_submission` or MCP tool `marketplace_submission_pack` when an Agent Store, A2A registry, Google-style Skill Registry, or partner reviewer needs one submission pack. It bundles listing metadata, required attachments, S2 review, S1 validation, billing boundaries, and claim limits. It does not submit to third-party marketplaces and the non-claim is `not_marketplace_approved`. Marketplace readiness. Use `/api/agent/marketplace_readiness` or MCP tool `marketplace_readiness_score` before human submission. It scores submission pack completeness, S1 validation, billing boundaries, claim safety, and target readiness, then returns blockers. A score of 100 means ready for human review only; it is not marketplace approval. Marketplace approval receipts. Use `/api/agent/marketplace_approval_receipts` or MCP tool `marketplace_approval_receipts` only after a platform returns a real approval receipt. Approval receipts prove listing presence only for listed platforms; the claim boundary is `approved_only_for_listed_platforms`. They do not prove runtime behavior, marketplace rank, AI recommendation, or conversion lift. Stored approvals appear as a redacted `optimization_history.marketplace_approvals` summary in AgentX.ID Passport, as `marketplace_approvals` evidence in Proof Graph, and on the public AgentX.ID identity page without raw receipt IDs. A2 citation evidence is strict: only observed AI answer rows count as AI visibility. Rows with proof artifacts are labeled `observed_with_artifact`; pasted real answer rows are `observed_manual_import`; unrun prompt rows are `manual_pending`; sample/mock rows are `synthetic_not_reportable`. If `verify_artifacts` is requested, proof URLs must be fetchable; failed fetches become `artifact_fetch_failed` and are not reportable AI visibility evidence. M1-M5 monthly reports can consume an A2 citation evidence package via `a2_citation_package` / `ai_citation_package` or CLI `--a2-package`. The dashboard preserves package hash, strict artifact verification mode, reportable rows, failed artifacts, pending rows, and synthetic rows separately. It reports observed evidence only and does not claim causality, guaranteed AI ranking, or conversion lift. M2/M3 convert A2 evidence gaps into `a2_content_gap_actions`: missing prompts become answer-first content rewrite tasks, failed artifacts become proof repair tasks, pending rows become prompt-run tasks, and all actions require publishing evidence plus a fixed-prompt rerun before improvement can be claimed. Verified website agents can call `/api/site_agents/call` with `action: "insights_feed"` and their Site Agent Key to poll a compact private work feed. The feed includes current work items, A2 content-gap actions, verification follow-ups, source hashes, claim limits, and next pull instructions. Keep the key server-side; browser SDK events are for signals only and do not directly modify a customer website. Node/server-side integrations can import `@twin3-ai/agent-id` and use `createSiteAgentClient().insightsFeed(...)` to call the same private feed. The helper requires a Site Agent Key and is intended for backend, CMS connector, worker, or website-agent runtimes, not public browser bundles. The same helper exposes `createSiteAgentClient().applyPlan(...)`. The apply plan converts the private feed into explicit execution routes: CMS content update, Worker / edge well-known files, or repository pull request. It is a plan and proof contract only; it does not apply changes without an authorized owner, connector, worker, or repository agent. For generated content work, use `createSiteAgentClient().contentPack(...)`. It returns an Agent-ready Content Pack that bundles answer-first rewrites, citation-gap work, prompt-test templates, publication evidence boundaries, and claim limits. A Content Pack is generated work; it is not an AI citation claim. For one-page content optimization, use `createSiteAgentClient().contentWorkflow(...)` or Site Agent private action `content_workflow_package`. It returns a C4 package with content diagnosis, answer-first rewrite, Schema guidance, white-hat community citation plan, citation-gap matrix, 30-day visibility plan, and C2 manual prompt-test sheet. This is generated work and a measurement protocol, not proof that ChatGPT, Gemini, Claude, Perplexity, or Google AI already cite the page. When C5 review blocks release, use `createSiteAgentClient().contentRepairPack(...)`, CLI `agent-id site-content-repair --key --review-gate `, MCP tool `site_agent_content_repair_pack`, or Site Agent private action `content_repair_pack`. It returns `agentx-c6-content-repair-pack-v0.1`: repair tasks, owner-review checklist, evidence-submit template, and claim boundaries. It creates executable repair deliverables only; it does not modify the customer site or prove AI citation/ranking. After C4 content is actually published, use `createSiteAgentClient().contentPublication(...)` or Site Agent private action `content_publication_package`. It returns an M8 package for accepted, rejected, verified, unverified, and pending publication evidence. This proves publication status only; it is not AI visibility, ranking, citation, or conversion proof. For fixed AEO/GEO measurement, use `createSiteAgentClient().promptTestCycle(...)`. The sequence is `prompt_test_run_sheet -> prompt_test_results`: first create a stable C2 buyer-question sheet, then import completed C3 rows only when a human/operator/authorized external evaluator supplies real AI answer results. This preserves comparable monthly measurement and does not fabricate AI citations. For A1 AI-read measurement, use `createSiteAgentClient().aiReads(...)` or Site Agent private action `a1_ai_reads`. Upload observed server/CDN logs from Cloudflare, CDN, nginx, or server collectors after domain verification. A1 proves observed AI crawler requests and read status only; it is not proof that an AI answer cited the site or that a conversion happened. To turn A1 rows into a reviewable customer deliverable, use `createSiteAgentClient().a1ReadPackage(...)` or Site Agent private action `a1_read_evidence_package`. The package summarizes observed reads, failed reads, providers, top paths, samples, evidence labels, and non-claims. It packages evidence; it does not create new crawler evidence. For B1 conversion attribution, use `createSiteAgentClient().conversions(...)` or Site Agent private action `b1_conversions`. Upload observed lead, RFQ, order, CRM, or survey events from a server-side runtime only. B1 is attribution evidence and not incrementality proof; compare it with A1/A2 trends and CRM baselines before claiming business lift. To turn B1 rows into a reviewable customer deliverable, use `createSiteAgentClient().b1ConversionPackage(...)` or Site Agent private action `b1_conversion_evidence_package`. The package summarizes observed AI-attributed conversions, source classes, redacted samples, CRM reconciliation gaps, evidence labels, and non-claims. It is still not incrementality proof. For M1 measurable outcome reporting, use `createSiteAgentClient().outcomeReport(...)` or Site Agent private action `outcome_report`. It combines observed G1/G2, A1, A2, B1, SDK, and job evidence into one outcome report. It reports observed evidence only; it does not prove causality or guaranteed lift. To package the M1 report as a reviewable deliverable, use `createSiteAgentClient().outcomePackage(...)` or Site Agent private action `m1_outcome_evidence_package`. To run both in sequence, use `createSiteAgentClient().outcomeReview(...)`. This produces the M1 report plus evidence package for the verified website Agent. For the continuous optimization loop, use `createSiteAgentClient().optimizationCycle(...)` or Site Agent private action `optimization_cycle`. O1 returns SDK evidence, G3 verification planning, I1 insights, job_drafts, and M1 outcome context in one read-only response. It does not accept drafts automatically, start jobs, modify the customer website, or prove business lift. To turn I1 insights or C5 review repairs into executable work, use `createSiteAgentClient().jobDrafts(...)` or Site Agent private action `job_drafts`. Pass `insights` from `optimizationCycle()` for I1 action drafts, or pass `review_gate` from `monthlyEvidenceLoop()` when `review_gate.repair_items` blocks release. Drafts are scoped AEO work proposals for the verified host only. They remain drafts until an owner or authorized website Agent explicitly calls `createSiteAgentClient().acceptJobDraft(...)`, `createSiteAgentClient().decideJobDraft(...)`, Site Agent private action `accept_job_draft`, or Site Agent private action `decide_job_draft`. `accept_job_draft` opens a job in the AEO ledger. It does not fund the job, release payment, prove delivery, or prove outcome improvement. Delivery still needs proof submission and evaluator review. For Agent billing, use `/api/agent/billing_guide` or MCP tool `agent_billing_guide` before checkout or job funding. It separates free routes, paid routes, checkout intents, and x402-style job payment flow. A checkout intent is not payment confirmation; the machine-readable non-claim is `checkout_intent_is_not_payment_confirmation`. x402-style proof remains off-chain until a provider is configured. `decide_job_draft` records accept, defer, or reject. Accept opens the same ledger job as `accept_job_draft`; defer and reject create an `agentx-draft-decision-v0.1` receipt only and do not start implementation work. To inspect prior draft decisions, use `createSiteAgentClient().draftDecisions(...)`, CLI `agent-id site-draft-decisions --key `, MCP tool `site_agent_draft_decisions`, or Site Agent private action `draft_decisions`. It returns `agentx-draft-decisions-v0.1` for the verified host only. M3 monthly tracker also surfaces these receipts as a `draft_decisions_review` workboard row, M5 monthly dashboard surfaces them as a `draft_decisions` KPI card, and M19 apply plan routes them through `owner_decision_review`. Applying evidence to that route returns `agentx-owner-decision-review-receipt-v0.1` and does not create a delivery job. To inspect those owner apply-plan review receipts later, use `createSiteAgentClient().decisionReviews(...)`, CLI `agent-id site-decision-reviews --key `, MCP tool `site_agent_decision_reviews`, or Site Agent private action `decision_reviews`. It returns `agentx-owner-decision-reviews-v0.1` for the verified host only. M3 surfaces them as a `decision_reviews_review` workboard row, M5 surfaces them as a `decision_reviews` KPI card, and the private feed can route them back through `owner_decision_review` without claiming delivery. `applyCycle()` will not apply a generic proof URL to `owner_decision_review`; pass explicit decision/review evidence when recording that receipt. This is decision history, not delivery evidence or outcome proof. For C5 repair work, the closed loop is: `monthlyEvidenceLoop()` returns `review_gate.repair_items`, `jobDrafts({ review_gate })` converts them into `agentx-c5-repair-job-drafts-v0.1`, `decideJobDraft(...)` records accept/defer/reject, `draftDecisions(...)` lets the website Agent inspect those receipts, accepted drafts open a `c5_content_workflow_repair` ledger job, and `reportJobEvidence(...)` or private action `report_job_evidence` attaches proof. M3 monthly tracker preserves `source_repair_item_id`, `source_check_id`, and `repair_route` so downstream agents can see exactly which failed C5 check was repaired. For a verified website agent's private C5 repair ledger, use `createSiteAgentClient().c5RepairHistory(...)`, CLI `agent-id site-c5-repairs --key `, MCP tool `site_agent_c5_repair_history`, or Site Agent private action `c5_repair_history`. The response schema is `agentx-c5-repair-history-v0.1`; it includes repair counts and redacted repair items, not raw proof hashes or private proof bodies. After evaluator review, M1 outcome report summarizes completed C5 repairs under `summaries.aeo_jobs.c5_repairs` and mirrors counts into `layers.delivery_jobs.c5_repair_total`, `c5_repair_completed`, `c5_repair_with_site_agent_evidence`, and `c5_repair_status`. These fields prove repair-job completion and evidence review only; they do not prove AI citation, ranking, conversion lift, or causality. AgentX.ID proof surfaces also expose this repair history. `agentx_proof_graph` returns `c5_repairs` plus a `c5_repairs` evidence node and graph node. `agentx_passport` returns `optimization_history.c5_repairs`. These surfaces let another agent verify which C5 checks were repaired, while keeping raw proof hashes and private evidence out of the public passport. For the full monthly evidence loop, use `createSiteAgentClient().monthlyEvidenceLoop(...)`. The base sequence is `content_pack -> content_workflow_review -> monthly_package -> monthly_tracker -> monthly_scorecard -> monthly_dashboard`; when C5 blocks release or citability findings need advisory repair, the sequence also returns `content_repair_pack` / `repair_pack` and `job_drafts` / `repair_job_drafts` before the monthly packages. The helper keeps one Content Pack, one C5 review, and when needed one C6 repair pack plus C5 repair job drafts shared across the monthly package, tracker, scorecard, and dashboard so downstream agents can distinguish generated work, evidence-boundary checks, repair deliverables, draft work proposals, publication evidence, observed AI reads, observed AI answer citations, and conversion evidence. External agents can discover the same workflow as MCP tool `site_agent_monthly_evidence_loop` or Site Agent private action `monthly_evidence_loop`; execution still requires a verified-domain Site Agent Key. monthlyEvidenceLoop request schema: - Required request field: url - Optional request fields: audit_url, questions, competitors, engines, content, content_pack, period - Secret source: SITE_AGENT_KEY in a server-side runtime only monthlyEvidenceLoop response schema: - Response fields: ok, action, pack, review, review_gate, repair_pack when blocked or advisory, repair_job_drafts when blocked or advisory, package, tracker, scorecard, dashboard, delivery_summary, steps - pack schema: agentx-content-optimization-pack-v0.1 - review schema: agentx-c5-content-workflow-review-v0.1 - review_gate schema: agentx-c5-review-gate-v0.1 - review_gate repair_items: deterministic failed-check repair tasks with route and next_step - repair_pack schema when blocked or advisory: agentx-c6-content-repair-pack-v0.1 - repair_job_drafts schema when blocked or advisory: agentx-c5-repair-job-drafts-v0.1 - delivery_summary.decision_queue: when repair_job_drafts are present, lists each draft awaiting accept / defer / reject; it does not accept or start jobs automatically - package schema: agentx-m2-monthly-optimization-package-v0.1 - tracker schema: agentx-m3-monthly-execution-tracker-v0.1 - scorecard schema: agentx-m4-monthly-outcome-scorecard-v0.1 - dashboard schema: agentx-m5-monthly-dashboard-v0.1