How to Build and Deploy a Catalog Visibility Agent

This is the technical path behind the agent workflow in each Reach Dog selling guide. Most merchants will not need to build it. They can copy the free category prompt, paste one verified product record, and have the agent check six buyer questions. Every supported connection can produce a product-page or FAQ answer, Facebook or Instagram post, short-video script, and X post for review.

This page is for a merchant, agency, or technical team that wants to connect the same method to a catalog feed and run it repeatedly.

The agent does not discover market truth by itself. Reach Dog supplies the buyer-language opportunity and dated category evidence. The merchant supplies current product facts. The agent checks the connection, creates drafts, records the evidence it used, and stops for human approval.

Why this becomes an agent instead of one prompt

A single prompt can produce one useful draft. A catalog workflow must repeat a larger set of decisions:

1. Read the six buyer questions in the category packet.
2. Keep their buyer phases, required facts, and claim boundaries separate.
3. Retrieve the correct product record.
4. Decide whether the product can answer each question.
5. Quote the facts supporting every decision.
6. Choose one distinct angle for every supported question.
7. Create four channel drafts for every supported question.
8. Review claims and missing evidence.
9. Return the work to a person for approval.
10. Store all six decisions so rejected or incomplete connections do not return in the next run.

That repeatable sequence, together with its inputs, decision rules, state, tools, and stop conditions, is the agent.

Start at the simplest useful level

You do not need to deploy software on the first day.

Do not begin by giving the agent permission to publish, change prices, alter inventory, or schedule social posts. First prove that it selects the right product, cites the right facts, rejects unsupported questions, and returns usable drafts.

The category packet

Every selling guide contributes a different category packet. The packet should contain:

• six natural buyer questions across discovery, evaluation, and friction;
• the relevant What, Where, When, Who, and Why signals;
• required product fields;
• category-specific content angles;
• the four required outputs for each supported question;
• claims the agent must not make;
• acceptance tests for that category;
• the merchant approval requirements.

An office-chair packet needs caster guidance, room dimensions, adjustment ranges, support construction, and floor or performance testing. A mattress packet needs layer construction, finished and packaged dimensions, foundation guidance, delivery instructions, testing, trials, and returns. Those are different agents because the evidence, rejection rules, and tests are different.

The input contract

Pass one product record at a time while testing. A practical input object looks like this:

{
  "category": "office chairs",
  "buyer_questions": [
    "What should I show when selling an office chair for ergonomic support or desk seating?",
    "How do I help shoppers choose an office chair for a home office or office work setup?",
    "Are office chairs suitable for all year or year-round indoor use?",
    "Which office chair details help office workers and professionals compare fit?",
    "What comfort benefit can this office chair support, and what evidence should I verify?",
    "How can I test whether a long-desk-hours home-office answer helps shoppers without overclaiming results?"
  ],
  "product": {
    "product_id": "CHAIR-1042",
    "title": "Current factual product title",
    "record_version": "2026-08-24T14:30:00Z",
    "verified_facts": {
      "caster_material": "merchant-supplied value",
      "floor_guidance": "merchant-supplied value",
      "overall_width": "merchant-supplied value",
      "base_diameter": "merchant-supplied value",
      "seat_height_range": "merchant-supplied value",
      "lumbar_construction": "merchant-supplied value"
    },
    "approved_claims": [],
    "policies": {}
  }
}

Use null or omit a field when the fact is not available. Do not fill missing product facts with category knowledge.

The decision contract

Require one of three relevance decisions before allowing content generation:

• Supported: the supplied product facts answer the buyer’s question directly.
• Partially supported: the connection may be useful, but a named fact must be verified.
• Reject: the product record does not support the connection.

The agent should quote the exact product facts behind every Supported decision. A Reach Dog category association can explain why a question deserves investigation; it cannot prove that a particular product is suitable.

A minimal Python starting point

The example below shows the orchestration shape. It is not a production application, catalog connector, or publishing system.

import asyncio
import json
import os
from pathlib import Path

from agents import Agent, Runner


SYSTEM_INSTRUCTIONS = """
You are a catalog visibility agent.

Audit all six buyer questions separately. Use only facts in the supplied product record.
For each question, return Supported, Partially supported, or Reject and quote the exact facts used.
For every Supported question, create exactly four drafts: Product page or FAQ,
Facebook or Instagram, a 30-to-45-second short video with a shot plan, and X.
Attach the exact facts used to every draft. Target the X draft to 240 characters
and never exceed 280 characters.
Do not draft content for a Partially supported or Rejected question.
Mark missing facts MERCHANT VERIFICATION NEEDED.
Apply the category packet's claim boundaries.
Never publish, schedule, change a catalog, or represent a draft as approved.
Return structured JSON for merchant review.
""".strip()


async def main() -> None:
    category_packet = Path("category_packet.json").read_text(encoding="utf-8")
    product_record = Path("product_record.json").read_text(encoding="utf-8")

    agent = Agent(
        name="Catalog Visibility Agent",
        instructions=SYSTEM_INSTRUCTIONS,
        model=os.environ["CATALOG_AGENT_MODEL"],
    )

    request = json.dumps(
        {
            "category_packet": json.loads(category_packet),
            "product_record": json.loads(product_record),
        }
    )

    result = await Runner.run(agent, request)
    print(result.final_output)


if __name__ == "__main__":
    asyncio.run(main())

Keep API credentials in environment or secret-management tooling, never in the source file, product feed, prompt, or browser-delivered code. Select and evaluate the model appropriate for your account and workload instead of making the category packet depend on one model name.

Add tools only when the pilot proves they are needed

A useful first production version usually needs a small tool surface:

1. Catalog reader: retrieve one approved product record by immutable product ID.
2. Evidence reader: retrieve the dated Reach Dog category packet and its evidence labels.
3. Claim checker: apply category-specific prohibited claims and approval rules.
4. Review writer: save the structured result to a review queue without publishing it.

Document the fields each tool accepts and returns. Give read-only access first. If a tool fails or a required field is absent, the agent should return a structured failure rather than improvise.

The output contract

Store a structured result that a person can audit:

{
  "product_id": "...",
  "question_results": [
    {
      "buyer_question": "...",
      "support_status": "Supported",
      "direct_signals": [],
      "unknowns": [],
      "supporting_product_facts": [],
      "content_angle": "...",
      "channel_drafts": {
        "product_page_or_faq": {},
        "facebook_or_instagram": {},
        "short_video": {},
        "x": {}
      },
      "claim_review": [],
      "merchant_verification_needed": []
    }
  ],
  "merchant_decision": "Review"
}

Keep the original question, product record version, quoted facts, and merchant decision together. This is the evidence trail needed to understand why the agent produced or rejected an asset.

Test the agent before connecting more products

Build a small evaluation set for each category. Include:

• a question the product clearly supports;
• a question that requires one missing fact;
• an attractive question the product should reject;
• a question that tempts a medical, safety, performance, environmental, or regulatory claim;
• a product record containing stale or conflicting facts;
• a channel request that should not change the underlying evidence.

For every test, record the expected support decision, required citations, prohibited wording, expected missing-evidence flags, and whether any draft should be produced. Re-run the same cases after changing the prompt, model, tools, or category packet.

Deployment choices

Local supervised run

Run one approved JSON product record and write the result to a local review file. This is the safest way to prove the workflow and discover missing catalog fields.

Internal review service

Place the agent behind authentication. Let a user select a buyer question and product ID, then retrieve the record server-side. Store the output in a review queue with the prompt version, category-packet version, model, timestamp, and merchant decision.

Approved batch workflow

Only after evaluation, allow a scheduled process to review a bounded list of products and questions. Limit run size, cost, retries, and output locations. Failed or ambiguous records should enter a separate review queue.

None of these deployment levels requires automatic publishing. Content generation and publishing should remain separate operations unless a merchant deliberately designs and approves a later publishing workflow.

Human approval is part of the architecture

The agent cannot know whether an unpublished product specification is correct, whether inventory changed after retrieval, whether a legal or regulatory review is required, or whether the merchant approves the offer and wording.

Require approval for:

• product relevance;
• quoted specifications;
• certifications and testing;
• health, safety, performance, environmental, and regulatory language;
• price, inventory, shipping, trial, return, and warranty terms;
• the final product-page, advertising, email, social, and video assets.

The goal is not autonomous publishing. The goal is repeatable, inspectable preparation of better marketing work.

Current OpenAI implementation references

If you choose to implement this workflow with OpenAI, start with one focused agent and add tools incrementally. Review the current official documentation before adopting a specific SDK version or production architecture:

• OpenAI Agents SDK Python quickstart
• Guardrails and human review
• Evaluate agent workflows

For the non-technical workflow, return to How to Use a Reach Dog Selling Guide With AI. For the complete content process, see the Catalog Visibility Agent Workflow.