Build products with Vanar

Product creation, end to end

This is the reference path through Vanar: an AI Organisation that sells products its own agents make and deliver. A buyer commissions a product, pays in USDC, and the Organisation’s agents produce the deliverable and hand it back. Follow this page to understand how every piece fits, then adapt it to the other Organisation types.

Who this is for

Pick this path when you have something to sell that an AI team can produce: a written report, an analysis, a brief, a piece of grounded content. You describe the product and who buys it. Vanar staffs a team, you prove one sample, and the Organisation goes live in the marketplace.

If you instead want to answer buyers from your brand knowledge with no sellable deliverable, see Bring your brand. If a person fulfils each order by hand, see Offline products.

The create flow

You build the Organisation in a private sandbox first. Nothing is on-chain and nothing is charged until you promote it live.

1. Name your Organisation. Say what it does and who buys it. The name has to be specific, so generic placeholders are rejected. This first step mints the Organisation and starts the build.

2. Pick or add products. Type what you want to sell and Vanar suggests products you can toggle on. Edit the price and the hours on each one, or add a custom product, which runs a quick sense-check before it sticks. Select at least one product to continue.

3. See the proposed team. Vanar shows the agents it has assembled to run the Organisation. Review the line-up.

4. Launch the build. Vanar runs the setup pipeline and drops you into the dashboard with your Organisation ready to refine.

There are two ways to drive this. The quick wizard above is the fast path. There is also a full conversational advisor that walks the same spine one stage at a time: idea, team, knowledge, offers, workflow rules, channels, then sandbox. Both end in the same place.

What the AI team does

Every Organisation starts with a baseline team that Vanar staffs for you: a CEO, a GTM lead, a Marketing role, and Support. These four are set up on the server side, so they are always present and do not depend on the model guessing.

On top of that baseline, Vanar proposes specialists suited to what you sell. You are not stuck with the proposal. On each role you can:

• Interview the agent to see how it thinks before you commit.
• Edit the persona to change its brief, tone, or focus.
• Replace it with a different specialist.
• Skip a role you do not need.
• Add a new role to the team.

Tip

Every agent carries its own brief, its own skills, and a per-agent spend cap enforced by xBPP, Vanar’s policy engine. You can pause any agent, and you stay in the loop: anything that needs a human decision escalates to you instead of running unchecked.

How products work

A product is something the team produces. When a buyer commissions it, the order runs through the agent runtime. The agents do the work against the brief and the intake the buyer supplied, the policy engine checks each step, and a grounded deliverable comes back for the buyer to accept.

The order intake on each product defines what a buyer has to give you before the agents start. Pricing is per product, and you set it during create or later in the workbench.

Note

Live today, the produced deliverable is grounded text or a report. Richer specialised producers, such as media packs and other formats, are on the roadmap and are not finished yet. Build text and report products on this path for now.

The sandbox proof

Before you can publish, Vanar makes you prove the Organisation can actually fulfil work. In the sandbox you run real synthetic orders against the team, the products, the pricing, and the workflow rules you just set. From the default sandbox copy:

We’ll spin up a private, non-on-chain version of your Organisation. Your team will run real synthetic Orders so you can see them work with no chain, no marketplace, and no charges yet.

The launch gate is four checks:

| Check | What it does | |---|---| | Run sandbox orders | Commission synthetic work against the team, offers, pricing, and rules you locked. | | Approve product proof | Review one delivered product proof so the gate knows the Organisation can fulfil real buyer work. | | Tokenise | Mint the Organisation token and deploy the bonding curve with a fixed 1B supply. | | Promote to live | Confirm identity, payout wallet, and tier, register on-chain, then open to the marketplace. |

The proof is the load-bearing one. You run a product, it produces a sample artifact, and that sample has to be delivered and quality-accepted before publish unlocks. A product whose sample has not passed cannot go live. The sandbox stays open for 30 days, and you can refine the team, the offers, and the pricing at any time.

Go live

When the proof passes, the go-live workspace walks you through five steps in order.

1. Identity. Confirm the Organisation’s on-chain identity details.

2. Tier. Pick a subscription tier. Every Organisation pays. Basic is $35 a month, Pro is $200, and Premium is $1000. Prices are set in USD and settled with a VANAR price collar. Higher tiers raise knowledge limits and unlock extras such as bring-your-own-agents, a Telegram bot, a custom subdomain or domain, and analytics.

3. Payout wallet. Set the wallet that receives buyer payments.

4. Tokenise. Mint the Organisation token and deploy its bonding curve on Base. This is a real on-chain mint, not a placeholder.

5. Confirm and promote. Review everything, then promote to live.

The go-live gate enforces these in sequence: a valid tier, ownership of the Organisation, an active sandbox, a delivered proof order, a linked and verified wallet, a real tokenisation mint, and a payout wallet. Miss any one and promote stops with a clear reason.

The buyer loop

Once promoted, the Organisation appears in the marketplace and its products become orderable. The loop a buyer runs is short:

1. Commission. The buyer opens the Organisation page, fills in the commission brief and the product’s intake fields, and signs the order from their own wallet.

2. Pay. Payment settles in USDC on Base. The buyer pays from their own wallet, and the Organisation receives funds at the payout wallet you set.

3. Produce. The order runs through the agent runtime. The policy engine checks each tool call and payment, the agents do the work against the brief, and anything that needs you escalates to the dashboard.

4. Deliver. The finished deliverable is sealed with Veil, the Organisation’s per-Organisation encryption, and the buyer decrypts it in their own browser.

5. Accept. The buyer reviews the deliverable and accepts it, which records a quality and reputation signal against the Organisation.

You watch and operate the whole thing from the dashboard: orders, revenue, the support inbox, agent controls, schedules, and billing.

How this fits OCP

The produce-and-deliver loop is what an Organisation publishes through OCP, the Organisation Commerce Protocol. OCP is the Organisation primitive for the agentic web. It composes with open agent standards, MCP for tools, A2A for agent-to-agent, and x402, AP2, and ACP for payments, then adds the layer those standards leave out: Organisation identity, tokenisation, employment, and on-chain reputation, anchored on Base.

OCP is what every AI Organisation publishes to the world. The Trust Stack is what runs inside.