Agent-See: Full Pipeline Plugin#

Convert any website, SaaS product, or API into a live, discoverable, agent-executable integration. This skill encodes the complete Agent-See workflow — from conversion through deployment, publication, backend connection, and ongoing maintenance.

Operating principle: Never stop at artifact generation. After every step, present the go-live status dashboard and proactively ask what's needed next. The conversion is the starting point, not the finish line.

Pre-flight (All Commands)#

Before running any agent-see command:

1. Check if agent-see is installed: bash

   agent-see --version 2>/dev/null
   
   

2. If not installed, auto-install from the repository: bash

   pip install git+https://github.com/Danielfoojunwei/Convert-any-SaaS-application-into-an-Agentic-interface.git --break-system-packages
   
   

3. If Python 3.11+ is not available, install via uv: bash

   uv python install 3.11
   uv venv --python 3.11 .venv
   source .venv/bin/activate
   uv pip install git+https://github.com/Danielfoojunwei/Convert-any-SaaS-application-into-an-Agentic-interface.git
   
   

4. For website/SaaS URL conversion, Playwright is required: bash

   playwright install chromium
   
   

---

Part 1: Pipeline Skills#

---

Skill 1: Convert Source#

Transform a website URL, SaaS product URL, or OpenAPI specification into a grounded agent bundle.

Determine Source Type#

User providesSource typeExampleA website URLWebsitehttps://example.comA SaaS product URLSaaShttps://app.example.comA local file path ending in .json, .yaml, or .ymlOpenAPI spec./openapi.json

If the source type is ambiguous, ask the user to clarify.

Run Conversion#

Set the output directory. Default to ./agent-output unless the user specifies otherwise.

bash

agent-see convert <source> --output <output-dir> --verbose

Post-Conversion Review#

Read and summarize the key outputs:

1. Read agent_card.json — confirm identity and discovery metadata
2. Read AGENTS.md — verify the agent/operator guidance is accurate
3. Read openapi.yaml — check the API contract was captured correctly
4. List skills/ — enumerate the business action wrappers generated
5. Read OPERATIONAL_READINESS.md — review execution boundaries

Present a structured summary:

• Number of skills/actions extracted
• Key workflows captured
• Any warnings about login, approval, or state-change boundaries
• Whether the bundle looks complete or needs re-running with adjusted scope

Handling Failures#

If conversion fails:

1. Read the error output carefully
2. Common issues:
   • Network errors: Check URL accessibility
   • Missing Playwright: Run playwright install chromium
   • OpenAPI parse errors: Validate the spec file format
3. Report the specific error and suggest remediation

Proactive Next Steps — DO NOT SKIP#

After conversion succeeds, immediately:

1. Run verification: agent-see verify <output-dir>/proof/proof.json

2. Present the go-live status dashboard showing what's done and what remains: StepStatusWhat's neededConversion✅ Done—Verification⏳ Running—Launch layer❌ Not startedBusiness name, domain, contact infoRuntime deployment❌ Not startedHosting platform choiceDiscovery publishing❌ Not startedWebsite accessBackend connection❌ Not startedReal API/database detailsMaintenance❌ Not startedSchedule preferences

3. Ask: "Should we continue with generating the launch layer, or do you want to deploy the server first?"

Conversion Output Artifacts Reference#

Core bundle files:

ArtifactDescriptionmcp_server/Callable tool surface for agents. Contains server.py, deployment configs (Dockerfile, docker-compose.yml, fly.toml, railway.json, render.yaml), and runtime metadata (route_map.json, tool_metadata.json, runtime_state.json).openapi.yamlMachine-readable API contract. All discovered endpoints, request/response schemas, auth requirements, rate limits.agent_card.jsonIdentity and discovery metadata. Agent name, description, capabilities, supported protocols, trust signals.AGENTS.mdHuman and agent-readable guidance. What the integration does, how to use it, operational boundaries, caveats.OPERATIONAL_READINESS.mdExecution boundaries. Auth requirements, state-changing operations, rate limits, known limitations.skills/*.mdIndividual business action wrappers (e.g., list_products.md, add_to_cart.md).skills/workflows/*.mdComposite workflow files chaining multiple skills (e.g., purchase_flow.md).proof/Grounding evidence: screenshots, DOM snapshots, API response samples, cross-validation reports.capability_graph.jsonStructured graph of capabilities and their relationships.

---

Skill 2: Verify Bundle#

Assess conversion quality across coverage, fidelity, and hallucination metrics.

Run Verification#

bash

agent-see verify <output-dir>/proof/proof.json

Interpret Results#

MetricHighMediumLowCoverage>80% — most actions captured50-80% — significant gaps<50% — re-run requiredFidelityFaithfully represents sourceSimplified/approximatedSignificant deviationsHallucinationNone detectedWeak grounding evidenceFabricated capabilities — must remove

Report to User#

Present a structured summary:

1. Overall quality score
2. Coverage gaps — workflows not captured
3. Fidelity issues — imprecise extractions
4. Hallucination flags — fabricated capabilities (critical)
5. Recommendation — proceed or re-run

Remediation#

Issue typeActionLow coverageRe-run conversion with adjusted scope or better accessLow fidelityRe-run with verbose modeHallucinationsRemove fabricated entries from skills/ and update agent_card.jsonMissing proofRe-run conversion to regenerate grounding evidence

---

Skill 3: Launch Artifacts#

Generate the public discovery and trust layer from an existing grounded agent bundle.

Pre-flight#

Confirm a grounded agent bundle exists:

bash

ls <output-dir>/agent_card.json

Launch Intake#

Check for or generate a launch intake file:

bash

agent-see launch init ./launch-intake.json \
  --name "<business name>" \
  --domain "https://<domain>" \
  --business-type <type> \
  --summary "<description>" \
  --contact-email "<email>" \
  --support-url "https://<domain>/support" \
  --agent-see-output-dir <output-dir> \
  --verbose

Key fields to confirm with the user: business name and URL, public page locations, trust signals, contact information.

Generate Launch Layer#

bash

agent-see launch sync ./launch-intake.json --verbose

Run Truthfulness Check#

bash

agent-see launch check <launch-output> --bundle <output-dir>

Post-Generation Review#

Read and summarize:

ArtifactWhat to checklaunch/llms.txtAccurately describes public pageslaunch/agents.mdTruthful agent access instructionslaunch/reference_layer/Supporting usage, limitation, trust, policy pageslaunch/launch_report.mdReadiness warningslaunch/surface_alignment.jsonPublic claims match runtime capabilitieslaunch/update_register.mdMaintenance plan

Launch Artifacts Reference#

ArtifactPurposellms.txtModel-facing guide at website root. Tells LLMs which pages are most important. Follows the llms.txt convention.agents.mdCanonical "how to use this integration" document. Actions, connection details, boundaries, contacts.Reference layerUsage guide, limitations, trust signals, policy page.Launch reportInternal readiness assessment. Checks artifacts generated, claims supported.Surface alignment JSONMachine-readable comparison: each claim tagged aligned, partial, or misaligned.Update registerMaintenance plan: trigger conditions, commands, expected outputs.

Proactive Next Steps — DO NOT SKIP#

After launch artifacts are generated, immediately:

1. Present the updated go-live status dashboard

2. Ask: "Launch layer is ready. These files need to be published on your website. Should we:"

   • "Deploy the MCP server first?" → trigger deploy-runtime
   • "Publish the discovery files now?" → trigger publish-discovery
   • "Connect to your real data first?" → trigger connect-backend

3. Recommend this order: deploy runtime → publish discovery (with real endpoint URL) → connect real data

---

Skill 4: Package Plugin#

Wrap a grounded agent bundle as a distributable plugin for a target harness.

Pre-flight#

Confirm bundle exists:

bash

ls <output-dir>/agent_card.json

Target Harness Selection#

Default to Claude workspace format. Supported targets:

HarnessDescriptionArtifact mixClaudeClaude workspaces / Cowork pluginsMCP runtime or OpenAPI, AGENTS guidance, plugin guideManusManus-style agentsMCP runtime, AGENTS guidance, skills, readiness outputsOpenClawOpenClaw-like orchestratorsRuntime metadata, agent card, route map, connector guideGenericAny other agent systemOpenAPI, AGENTS guidance, plugin manifest, starter kit

Run Plugin Packaging#

bash

agent-see plugin sync <output-dir> --launch-output <launch-output> --verbose

Post-Packaging Review#

ArtifactPurposeplugins/plugin_manifest.jsonMachine-readable inventory of the grounded bundleplugins/PLUGIN_GUIDE.mdStep-by-step usage for target harnessplugins/connectors/Harness-specific connection guides (claude_workspace.md, manus.md, openclaw.md, generic.md)plugins/starter_kit/Templates: plugin_template.md, skill_template.md, connector_template.md

Harness-Specific Packaging Reference#

Claude Workspaces / Cowork:

text

plugin-name/
├── .claude-plugin/
│   └── plugin.json
├── skills/
│   └── skill-name/
│       └── SKILL.md
├── .mcp.json          (if runtime endpoint exists)
└── README.md

MCP integration in .mcp.json:

json

{
  "mcpServers": {
    "agent-see-runtime": {
      "command": "python",
      "args": ["${CLAUDE_PLUGIN_ROOT}/mcp_server/server.py"],
      "env": { "API_BASE_URL": "${API_BASE_URL}" }
    }
  }
}

Manus-style agents: MCP endpoint URL + tool_metadata.json + skills + AGENTS.md

OpenClaw-like orchestrators: agent_card.json registered with discovery service + route_map.json + capability_graph.json + thin protocol connector

Generic harnesses: OpenAPI spec + AGENTS.md guidance + plugin manifest + starter kit templates

---

Part 2: Go-Live Skills#

---

Skill 5: Go Live (Master Orchestrator)#

Proactive end-to-end orchestrator that guides a business owner from a completed conversion all the way to a live, discoverable, agent-executable integration.

Operating Principle#

The conversion is the starting point, not the finish line. A converted business needs to become easy for agents and LLMs to retrieve, understand, trust, and act on. This means operating two layers simultaneously: the human-facing website and the machine-facing agent integration surface.

Step 0: Assess Current State#

Read the bundle directory and present a status dashboard:

StepStatusWhat's neededConversion✅/❌Source URL or OpenAPI specVerification✅/❌Run agent-see verifyLaunch layer✅/❌Business name, domain, contact infoRuntime deployment✅/❌Hosting platform choiceDiscovery publishing✅/❌Website access or hosting detailsBackend connection✅/❌Real database/API credentialsStructured data✅/❌Website template accessMaintenance loop✅/❌Schedule preferences

Ask: "Which of these do you want to tackle next, or should we go through them in order?"

Step 1: Confirm Canonical Task URLs#

For each extracted capability, suggest a corresponding URL:

CapabilitySuggested URLUser intent it answerslist_products/products or /menu"What do you sell?"get_product_details/products/{slug}"Tell me about this item"add_to_cart/cart"I want to buy this"submit_checkout/checkout"I'm ready to pay"get_order_status/orders/{id}"Where's my order?"

Ask: "Do these URLs exist on your site? Which ones need to be created or updated?"

Step 2: Page Rewriting Guidance#

For each canonical URL, the top of the page must immediately answer: who the offer is for, what action can be completed, what inputs are required, what constraints exist, and what the next step is.

Ask: "Do you want help rewriting any of these pages? I can generate answer-first content based on your converted capabilities."

Step 3: Deploy the Runtime#

Trigger Skill 6: Deploy Runtime. Ask:

• "Where do you want to host the MCP server? Docker, Fly.io, Railway, or Render?"
• "Do you have an account on any of these platforms?"
• "What's the base URL of your actual API?"

Step 4: Publish Discovery Files#

Trigger Skill 8: Publish Discovery. Ask:

• "Do you have access to upload files to your website root?"
• "What's your website's domain?"
• "Do you use a CMS (WordPress, Shopify, etc.) or static hosting?"

Step 5: Create the Agent Integration Page#

Help the user create a public /agents page from launch-output/agents.md. Ask:

• "Do you want this as a standalone page or part of your existing docs?"
• "Should it link to the live MCP endpoint or the OpenAPI spec?"

Step 6: Add Structured Data#

Generate JSON-LD snippets based on business type:

• Organization for the homepage
• Product for product pages
• FAQPage for FAQ
• BreadcrumbList for navigation

Step 7: Establish Identity and Trust#

Ask about Search Console verification, Google Business Profile, and contact detail consistency across web properties.

Step 8: Connect to Real Data#

Trigger Skill 7: Connect Backend. Ask:

• "What database or API serves your real product/order data?"
• "What authentication does your backend use?"
• "Do you have a staging environment?"

Step 9: Set Up Maintenance#

Trigger Skill 9: Maintain. Ask:

• "How often does your menu/catalog change?"
• "Do you want automatic re-sync reminders?"

Step 10: Final Verification#

1. Verify MCP server health endpoint responds
2. Confirm llms.txt is publicly accessible
3. Confirm /agents page is live
4. Run agent-see launch check for surface alignment
5. Test each capability end-to-end if possible

Present a final go-live report.

Proactive Chaining Rule#

After ANY skill completes (convert, verify, launch, package), immediately present this status dashboard and offer to continue with the next incomplete step. Do not stop at artifact generation.

---

Skill 6: Deploy Runtime#

Deploy the generated MCP server so agents can call it over the network.

Pre-flight#

Confirm mcp_server/server.py exists in the bundle output.

Gather Required Configuration#

Ask the user for every required setting before deploying.

Mandatory:

SettingEnvironment variableWhat to askTarget API URLTARGET_URL"What's the base URL of your real API that this server should proxy to?"PortPORTDefault 8000 unless specified

Authentication (ask which applies):

MethodVariablesWhat to askBearer tokenAUTH_TOKEN"Does your API use a bearer token?"Custom headerAUTH_HEADER_NAME, AUTH_HEADER_VALUE"Custom auth header name and value?"None—"Is the API publicly accessible?"

Operational limits:

SettingVariableDefaultRequest timeoutREQUEST_TIMEOUT_MS30000Max retriesMAX_RETRIES3Session TTLSESSION_TTL_SECONDS3600Max sessionsMAX_SESSIONS100

Platform Deployment#

Docker (Local or VPS):

bash

cd <output-dir>/mcp_server
cp .env.example .env
# User fills in .env values
docker-compose up -d

Fly.io:

bash

cd <output-dir>/mcp_server
fly launch --no-deploy
fly secrets set TARGET_URL=<value> AUTH_TOKEN=<value>
fly deploy

Railway:

bash

cd <output-dir>/mcp_server
railway init
railway up

Render: Push mcp_server/ to a Git repo and connect via Render dashboard.

Post-Deployment Verification#

1. Health: curl <deployed-url>/health
2. Tools: curl <deployed-url>/tools
3. Test read-only tool: Call list_products and verify real data
4. Check logs: Confirm no errors

Security Checklist#

• TARGET_URL points to correct backend
• Auth credentials set as secrets, not in code
• HTTPS enabled
• Health endpoint responds
• Rate limits configured
• Session TTL prevents unbounded memory growth

Record the Endpoint#

After deployment, record the live URL. Ask: "Deployment is live at <url>. Should we continue with publishing discovery files?"

Production Readiness Checklist#

Configuration:

• TARGET_URL set and correct
• Auth credentials as environment secrets
• Request timeout configured ( REQUEST_TIMEOUT_MS)
• Max retries with backoff ( MAX_RETRIES)
• Session TTL ( SESSION_TTL_SECONDS)
• Max concurrent sessions bounded ( MAX_SESSIONS)

Runtime Safety:

• Health endpoint at /health
• Readiness endpoint confirms backend connectivity
• HTTPS enabled
• No hardcoded credentials
• Docker runs as non-root user (if Docker)

Execution Resilience:

• Retry policies with exponential backoff
• Request timeouts prevent hanging
• Error responses follow typed format (NOT_FOUND, AUTH_FAILED, RATE_LIMITED, etc.)

Session Management:

• TTL expires inactive sessions
• Max count prevents memory exhaustion
• Cleanup runs on schedule or LRU eviction

Approval Governance:

• State-changing operations require confirmation
• Payment operations require human approval
• Destructive operations blocked by default

Known Limitations:

• Browser automation is fragile — scope conservatively
• Best against SaaS with stable APIs
• In-memory session state lost on restart — use external storage for production
• Generated servers are "validated operational prototypes" — review before production hardening

---

Skill 7: Connect Backend#

Wire the generated MCP server to real data sources.

Pre-flight#

Read route_map.json and tool_metadata.json to understand what endpoints exist.

Identify the Data Source#

Ask the user:

1. "Where does your real product/service data live?"

   • Existing REST API (most common for SaaS)
   • Database (PostgreSQL, MySQL, MongoDB, etc.)
   • E-commerce platform (Shopify, WooCommerce, Stripe, Square)
   • Spreadsheet or static file
   • Multiple sources

2. "Is there API documentation or an OpenAPI spec for your backend?"

3. "What authentication does your backend require?"

   • API key / OAuth2 / Basic auth / Session / None

4. "Do you have a staging/test environment, or should we work against production?"

Connection Strategy by Data Source#

Existing REST API:

1. Update TARGET_URL to point to the real API

2. Map each MCP tool to corresponding real endpoint: MCP ToolGenerated routeReal API endpointlist_productsPOST /tools/list_productsGET /api/productsadd_to_cartPOST /tools/add_to_cartPOST /api/cart/items

3. Adjust request/response transformations if schemas differ

4. Set authentication headers

Database Direct:

1. Add database connection layer to server.py
2. Get connection details (host, port, db name, credentials as env vars)
3. Write query functions per tool
4. Add connection pooling and error handling

E-commerce Platform (Shopify, WooCommerce, Square):

1. Get platform API credentials
2. Update MCP server to use platform API
3. Map generated tool schema to platform endpoints
4. Handle platform-specific pagination, rate limits, auth

Spreadsheet or Static File:

1. Load data into MCP server as in-memory store
2. Implement read operations against loaded data
3. For writes, set up SQLite or notification system

Tool-by-Tool Wiring#

For each capability:

1. Read the generated skill file — understand expected inputs/outputs
2. Identify the real data source
3. Map the schema — align generated parameter names with real field names
4. Handle authentication
5. Test the connection
6. Update server.py

Testing Protocol#

1. Read-only tools first: list_products, get_product_details
2. State-reading tools: get_cart, get_order_status
3. State-changing tools last: add_to_cart — staging only
4. Never test checkout against production without explicit approval

After all tools connected, run the complete workflow end-to-end.

---

Skill 8: Publish Discovery#

Place generated discovery and trust files on the business's actual web surface.

Gather Website Details#

Ask before proceeding:

1. "What is your website's domain?"
2. "How do you manage your website?" (Static hosting / CMS / Custom server)
3. "Do you have access to upload files to the website root?"
4. "Do you already have a robots.txt and sitemap.xml?"

File-by-File Publication Guide#

1. robots.txt

Ask: "Do you want AI search crawlers to find your site?"

text

User-agent: *
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: Applebot
Allow: /

Sitemap: https://<domain>/sitemap.xml

Ask: "Allow AI training crawlers too, or only search/user-directed access?"

2. sitemap.xml

Generate XML sitemap with all canonical task URLs and accurate lastmod dates.

xml

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://<domain>/</loc>
    <lastmod>YYYY-MM-DD</lastmod>
    <changefreq>weekly</changefreq>
  </url>
</urlset>

3. llms.txt

Update the generated llms.txt with actual deployed runtime endpoint and real domain URLs. Place at https://<domain>/llms.txt.

4. /agents Page

Customize launch-output/agents.md with real endpoint URLs. Ask: "HTML page, markdown, or CMS-pasteable content?"

5. Reference Layer Pages

coverage.md, limitations.md, pricing_eligibility.md, support_escalation.md, change_policy.md

Ask: "Separate pages or combined into one reference page?"

6. Structured Data (JSON-LD)

Generate snippets based on business type:

Homepage — Organization:

json

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "<business name>",
  "url": "https://<domain>",
  "logo": "https://<domain>/logo.png",
  "contactPoint": {
    "@type": "ContactPoint",
    "email": "<support email>",
    "contactType": "customer service"
  }
}

Product pages — Product:

json

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "<name>",
  "description": "<description>",
  "offers": {
    "@type": "Offer",
    "price": "<price>",
    "priceCurrency": "<currency>",
    "availability": "https://schema.org/InStock"
  }
}

7. IndexNow Setup

Ask: "Want search engines notified automatically when content changes?" If yes, generate key file and provide submission URL format.

Platform-Specific Instructions#

PlatformHow to publishNetlify/VercelAdd files to public/ or static/, deploy normallyWordPressFile manager plugin or FTP for root files; WP admin for pages; structured data via pluginShopifyTheme editor for JSON-LD in theme.liquid; pages for /agents contentCustom serverPlace in static/public directory; add routes for /agents and reference pages

Verification#

bash

curl -I https://<domain>/robots.txt
curl -I https://<domain>/sitemap.xml
curl -I https://<domain>/llms.txt
curl -I https://<domain>/agents

---

Skill 9: Maintain#

Keep the agent-facing surface aligned with the real business.

Determine What Changed#

Ask: "What changed in your business?"

Change typeWhat needs refreshingProducts/menu added or removedRe-run conversion, update sitemap, product pages, IndexNowPrices changedUpdate product pages, schema markup, sitemap lastmod, IndexNowPolicies changedUpdate policy pages, reference layer, sitemap lastmodWorkflows changedRe-run conversion, redeploy runtime, update /agents pageAuth or access changedRe-run conversion, update MCP server config, update /agents pageContact/support info changedUpdate Organization markup, Business Profile, support pagesNew capability addedRe-run conversion, refresh all downstream layersBranding or domain changeUpdate all URLs in llms.txt, sitemap, agents page, structured data

Re-sync Protocol (Follow This Order)#

1. Re-run Conversion (if business logic changed):

bash

agent-see convert <source> --output <output-dir> --verbose
agent-see verify <output-dir>/proof/proof.json

2. Refresh Launch Layer:

bash

agent-see launch sync <launch-intake.json> --bundle <output-dir> --output <launch-output>
agent-see launch check <launch-output> --bundle <output-dir>

3. Refresh Plugin Layer:

bash

agent-see plugin sync <output-dir> --launch-output <launch-output>

4. Redeploy Runtime (if server code changed)

5. Update Published Discovery Files:

• sitemap.xml with new/changed URLs and accurate lastmod
• llms.txt if pages or capabilities changed
• /agents page if capabilities or connection details changed
• JSON-LD structured data if product/pricing data changed
• Submit changed URLs via IndexNow

6. Verify Alignment:

1. Check MCP server health
2. Confirm llms.txt is current
3. Confirm /agents page reflects actual capabilities
4. Run agent-see launch check

Maintenance Cadences#

CadenceWhat to reviewWeeklyBroken links, stale prices, runtime uptime, support details, primary CTAsMonthlySearch Console signals, sitemap freshness, robots.txt, schema validityAfter every material changeRe-run Agent-See, redeploy runtime, update discovery files, IndexNowQuarterlyReassess customer prompts, add task pages, review competitor gaps, expand reference pages

Drift Detection#

Signs the agent surface has drifted:

• Agents returning products that no longer exist
• Prices in structured data don't match website
• /agents page lists removed capabilities
• Launch alignment check reports failures
• Customer complaints about incorrect agent behavior

If drift detected, run the full re-sync protocol immediately.

---

Part 3: Reference Material#

---

Agentic Search Playbook#

The Four Decisions#

A business becomes strong in the prompt economy when it wins four decisions inside a model pipeline: whether the business is retrieved, whether it is selected, whether it is trusted, and whether it can be executed immediately.

LayerGoalBusiness owner must doAgent-See providesDiscoveryGet retrievedPublish crawlable, text-rich, task-shaped pages and discovery filesRuntime artifacts and machine-usable operational surfaceSelectionGet recommendedMake use cases, fit, constraints, pricing, policies explicitStructured description of actions and workflowsTrustGet cited as safeMaintain entity data, support info, policy pages, visible consistencyClear workflow boundaries, auth notes, approval-sensitive actionsExecutionLet agents actDeploy the runtime and expose clear connection guidanceMCP/OpenAPI/runtime outputs and harness-facing artifactsMaintenanceStay freshUpdate pages, feeds, schema, sitemaps, re-run conversionRegeneration path for the executable surface

10-Step Operational Sequence#

1. Choose canonical task URLs — Every core commercial action gets a dedicated URL
2. Rewrite pages as answer-first — Title states the task, opening paragraph states audience + action + next step
3. Publish discovery files — robots.txt, sitemap.xml (with accurate lastmod), llms.txt, markdown mirrors
4. Add structured data — JSON-LD for Organization, Product, FAQPage, BreadcrumbList
5. Establish identity — Search Console, Business Profile, consistent contact details
6. Make offers comparable — Visible pricing, variants, availability, shipping, returns, warranties
7. Publish agent integration page — /agents page connecting discovery to execution
8. Push updates fast — IndexNow, sitemap refresh, re-run Agent-See on business logic changes
9. Build reference layer — Coverage, limitations, pricing/eligibility, policies, examples, support
10. Maintain continuously — Weekly, monthly, quarterly, and on-change review cadences

Answer-First Page Format#

Every high-value page must immediately answer: who the offer is for, what action can be completed, what inputs are required, what constraints exist, and what the next step is.

Discovery File Placement#

FileLocationPurposerobots.txtWebsite rootControl crawler access intentionallysitemap.xmlWebsite rootComplete URL inventory with accurate lastmodllms.txtWebsite rootCurated guide for models to find highest-value pages/agents pagePublic docs or siteConnection instructions for agents

Structured Data Priority#

Page typeSchema typeWhyHomepageOrganizationOfficial identity, logo, contactsProduct pagesProductPrice, availability, ratings, shippingFAQFAQPageDirect answers to recurring objectionsNavigationBreadcrumbListPage hierarchy and topical relationships

Key Principle#

Do not invent capabilities in the launch or plugin layer. Extract the real business surface first, then wrap it with thin public guidance and thin harness-specific packaging.