Build a Grounded AI Agent for Marketplace Ops

Grounding an agent is a concept. Building one is six fields. This is the literal walkthrough — name it, scope it, pick a model, attach your documents, allowlist its integrations, and write the prompt — for a marketplace operations specialist that answers from your own runbooks.

Most advice about AI agents stops at the idea. Scope it narrowly, ground it in your documents, keep a human on the irreversible step — all true, all abstract. At some point you open Insulin, click + New agent, and have to fill in an actual form.

This is that form, in order, for one concrete case: a marketplace operations agent that answers listing, offer, and entitlement questions from your own playbooks rather than from a model’s general read of how AWS, GCP, and Azure Marketplaces usually work. Six decisions, each with a right answer for this kind of agent.

If you want the why behind grounding first — what changes when an agent reads your documents instead of guessing — start with how to ground an AI agent in your documents. This post is the build.

How do I ground an AI agent in my own docs for marketplace ops?

You ground an agent by attaching a knowledge base to it, then filling in five more fields that scope its behavior. In Insulin an agent is “a specialized AI assistant scoped to a single task or business domain,” and creating one means giving it a name, an ownership level, a model, its knowledge bases, its integrations, and a system prompt. Grounding is one of those six steps, not a separate project.

The Agents docs list the create-an-agent fields directly: a descriptive name, whether it is personal or shared with your organization, a default model, “any knowledge bases in read or edit mode,” an integration allowlist, and “the system prompt that defines its behavior.” Work through them in that order and you have a grounded specialist at the end.

Step 1 — Name it

Give the agent a name that says exactly what it owns. Insulin lets you “give it a name and icon” — treat that as the first scoping decision, not a label you paste on afterward.

Call it Marketplace Ops, not “Assistant.” The name is how teammates find it, how you tell it apart from the deal desk agent in a shared channel, and a quiet reminder of its remit. A vague name invites vague questions; a precise one keeps people asking it the thing it is actually grounded to answer.

Step 2 — Choose personal or shared

Decide who the agent belongs to before you configure anything else, because that choice controls who can use it. Insulin asks you to “choose whether it is personal or shared with your organization” — a user-level agent stays private to you, and an organization-level agent can be shared with role-based access.

For marketplace ops, shared is almost always right: listing and offer questions are a team’s questions, not one person’s. When you share it, Insulin’s access model lets you grant admin, editor, or user roles, “either to named people or to everyone in the organization at once.” Give editors to the people who will maintain its prompt and knowledge, user access to everyone who just needs answers.

Keep an agent personal when it is genuinely yours — an experiment, or something wired to your own credentials. If you are unsure, start personal and promote it once it earns the team’s trust. If you want the full breakdown of who sees what, role-based access for AI workspaces covers it.

Step 3 — Pick the model

Pick the model that matches the work, because a triage agent and a deep-analysis agent do not need the same one. Insulin lets you “pick its default model” per agent, drawn from your connected providers, so this is a per-agent decision rather than a workspace-wide setting.

Marketplace ops is mostly lookup and policy application — “is this listing missing a pricing dimension,” “does this discount need approval.” That is not the work that demands your heaviest reasoning model on every turn. A balanced model answers fast and cites correctly, which is what this agent is for. You can always raise it later; you cannot get back the latency you spend over-provisioning a lookup agent.

Step 4 — Attach knowledge bases in read or edit mode

This is the grounding step, and it is where a marketplace ops agent stops guessing. Insulin lets you “attach any knowledge bases in read or edit mode,” and once attached, the agent searches those bases before it answers and cites the source document for each result.

Attach the bases that hold the material governing the work — a listing playbook, your pricing and packaging policy, private-offer approval rules. The docs are explicit about the mechanism: “Agents retrieve context by searching the knowledge bases available to them,” and each result carries “the source document” it came from. So when someone asks which listings are missing a current pricing dimension, the answer arrives with the playbook page behind it, not a plausible paragraph you have to trust on faith.

Two modes, two different intents:

Read — the agent searches the base and cites from it, but cannot change it. This is the default for a marketplace ops agent. It answers from your policy; it does not rewrite it.
Edit — the agent can also create, update, and deprecate files in the base. Reserve this for an agent whose job is to maintain the documents, not merely consult them.

Scope is the boundary here exactly as it is with integrations: “an agent only reaches the bases you attach to it.” Attach the marketplace playbooks and nothing else, and the agent physically cannot cite your finance runbooks at a listing question. An agent can also search up to three knowledge bases in a single turn, so a marketplace ops specialist can span listings, offers, and entitlements without you merging three policies into one messy base.

Start with one domain and one base attached in Read mode. A single well-grounded specialist beats several that retrieve loosely.

Step 5 — Allowlist its integrations

Grant the agent only the connected systems its work requires — the allowlist is the boundary that keeps it inside its job. Insulin lets you “allowlist the integrations it may use,” and describes scoped integrations as granting “access only to the connected systems the agent needs,” because “scope is the boundary, so an agent cannot reach data outside its job.”

For a marketplace ops agent, that means the systems behind listings, offers, and entitlements — plus your CRM if it needs to cross-reference a deal. It does not mean everything you have connected. Every integration you leave off the allowlist is a class of data this agent cannot touch, which is precisely what makes its behavior predictable and safe to hand to the team.

The allowlist governs actions, not just reading. When the agent proposes a plan that touches an integration, Insulin runs tool execution “through approval workflows in chat” — “you see the plan and approve it before anything happens.” So the allowlist decides what is possible and the approval step decides what actually runs. If you want that irreversible-step discipline spelled out, human approval for AI agents makes the case.

Step 6 — Write the system prompt

Write the system prompt last, once the scope is set, because it fixes the behavior inside that scope. Insulin’s system prompt is “a system prompt that fixes the agent’s remit, tone, and the rules it must follow — so a finance agent behaves like finance, not like a general chatbot.” It is “the system prompt that defines its behavior.”

For a marketplace ops agent, three things belong in it:

Its remit — that it handles marketplace operations, and what it should decline or hand off.
A grounding rule — check listing and offer state, and cite the source document, before answering. This is what makes the citation a habit rather than an accident.
Its tone and guardrails — how definitive to be, when to ask for a human, what it must never assert without a source.

A working example, using fictional stand-ins where names would otherwise appear:

You handle marketplace operations for Acme. Before answering, search the attached Listing Playbook and Offer Policy knowledge bases and check current listing and offer state. Always cite the source document. If a question falls outside marketplace ops — a legal or pricing-approval decision — say so and point the user to the deal desk. Never state a fee, eligibility rule, or program requirement without a cited source.

That prompt does not make the agent smart. It makes the agent consistent — every answer runs through the same grounding-and-citing discipline, whether a person is watching or a scheduled job fired it at four in the morning.

What you have at the end

Six fields in, you have a specialist. It is named for its job, shared with the team at the right access level, running a model sized for lookup, grounded in your own marketplace playbooks with a citation on every answer, allowlisted to only the systems its work touches, and prompted to check state and cite before it speaks.

From here, two things extend it without any rebuild. Put it on a schedule with scheduled AI jobs so a grounded run lands in someone’s inbox every morning — the grounding travels into the job unchanged. And if a teammate wants the same capability, the knowledge base and scope go with the agent; they do not have to reconstruct your six decisions from memory.

Frequently asked questions

How do I ground an AI agent in my own docs for marketplace ops? Create a knowledge base holding your marketplace playbooks and policies, then attach it to the agent in Read mode. The agent searches that base before answering and cites the source document for each result, so answers reflect your own rules rather than the model’s general training.

What are the steps to build an agent in Insulin? Give it a name and icon, choose whether it is personal or shared, pick its default model, attach any knowledge bases in read or edit mode, allowlist the integrations it may use, and write the system prompt that defines its behavior.

Should a marketplace ops agent be personal or shared? Usually shared. Listing and offer questions are a team’s, not one person’s. A shared agent supports role-based access — admin, editor, or user — granted to named people or everyone at once. Keep it personal only for experiments or agents wired to your own credentials.

What is the difference between Read and Edit mode for a knowledge base? In Read mode the agent searches the base and cites from it but cannot change it — the default for answering. In Edit mode it can also create, update, and deprecate files. Reserve Edit for an agent whose job is to maintain the documents.

How many knowledge bases can one agent search? An agent only reaches the bases you attach to it, and it can search up to three knowledge bases in a single turn. That lets a marketplace ops agent span listings, offers, and entitlements without merging separate policies into one base.

What should go in the system prompt for a marketplace ops agent? Its remit, a grounding rule, and its guardrails. State that it handles marketplace operations, instruct it to check listing and offer state and cite the source before answering, and tell it never to state a fee or program rule without a cited source.

Takeaways

Building a grounded agent is six fields, in order: name, ownership, model, knowledge bases, integrations, system prompt.
Name it for its job and share it with the team at the right access level — marketplace ops is a team’s question, not one person’s.
Size the model for the work; lookup and policy application do not need your heaviest reasoning model on every turn.
Attach knowledge bases in Read mode to ground it — the agent searches your documents first and cites the source on every answer, across up to three bases per turn.
Allowlist only the integrations its work touches, and write a prompt that makes checking state and citing sources a habit.

Build a document-grounded marketplace operations agent, attach an AI knowledge base so every answer cites your own playbooks, and read the Suger Insulin docs for the full field-by-field reference.

How to Build a Grounded AI Agent for Marketplace Ops