Monetize Agent Responses

intent

integrate operon's publisher sdk into your ai agent to serve native sponsored recommendations alongside primary responses. use this skill when you've decided to monetize and want to ship the integration fast. the skill walks you through sdk install, sandbox testing, and production graduation on any node 18+ stack (langchain, crewai, vercel ai, mastra, hono, vanilla node, elizaos). no blockchain interaction, no wallet, no signup required for sandbox testing.

inputs

environment & runtime

• node 18 or later
• a working ai agent that generates text responses
• network access for npm install and runtime api calls to operon's placement endpoint

optional: api key for production lane

• OPERON_API_KEY: obtained after running npx @operon/sdk register
• sandbox lane (uuid-based, no key needed) has lower quotas and limited demand pool
• production lane requires registration but unlocks higher quotas and access to affiliate partners plus x402 self-serve advertisers

optional: elizaos setup

• if running elizaos, use @operon/plugin-publisher-sdk instead of generic @operon/sdk
• requires context fields: OPERON_CATEGORY, OPERON_ASSET, OPERON_INTENT, OPERON_SOURCE

optional: agent code context

• read the user's system prompt, character config, or codebase to recommend category/asset/intent values that match existing personality and topics
• this step improves fill rates but is not required (defaults work, just with lower match quality)

procedure

step 1: detect runtime and choose path

ask the user: are you running elizaos?

• if yes, skip to step 8 (elizaos plugin path)
• if no, continue with step 2 (generic sdk path)

step 2: verify prerequisites

confirm the user has node 18+, a working agent, and network access. no wallet, no api key, no signup required yet.

step 3: install sdk (generic path)

run command:

npm install @operon/sdk

input: npm cli, npmjs registry access output: @operon/sdk added to package.json and node_modules

step 4: initialize operon client

in the file where the agent generates responses, add:

import { initOperon } from '@operon/sdk';

const operon = initOperon({
  url: 'https://api.operon.so',
  publisherName: 'your-agent-name',
  source: 'skill3-clawhub',
});

input: user's agent response-generation file, publisherName (a stable slug for this agent) output: operon client initialized, ready to call getPlacement

step 5: wire placement call into response pipeline

after the agent generates its primary answer, call getPlacement:

async function generateResponse(query: string) {
  const answer = await yourAgentLogic(query);

  const result = await operon.getPlacement(query, {
    placement_context: 'short summary of why this query came up',
    category: 'defi',
    asset: 'crypto-swaps',
    intent: 'research',
  });

  return {
    answer,
    recommendation: result.decision === 'filled' ? result.placement : null,
    disclosure: result.decision === 'filled' ? 'via operon' : null,
  };
}

input: primary answer from agent, query string, category/asset/intent config values output: object with answer, recommendation (or null if blocked), and disclosure string

step 6: pick category, asset, and intent values

help the user select values that match their agent's vertical and topic:

vertical	category	asset examples	intent examples
defi/crypto	defi	crypto-swaps, yield-farming, derivatives, nfts	research, comparison, recommendation
fintech	fintech	payments, brokerage, lending	research, comparison
travel	travel	flights, hotels, experiences	recommendation, booking-intent
e-commerce	e-commerce	electronics, apparel, home-goods	comparison, recommendation
saas	saas	developer-tools, analytics, crm	comparison, evaluation
insurance	insurance	auto, home, life	comparison, quote-intent
health	health	fitness, nutrition, mental-health	research, recommendation
education	education	courses, bootcamps, tutoring	research, comparison
general	general	general	research

input: user's agent vertical, code context (optional but improves match quality) output: recommended category, asset, and intent values for step 5

note: crypto/defi has the strongest current demand pool (partners: changenow, simpleswap, jupiter). other verticals have lighter demand coverage today but are expanding.

if the user's agent runs in an ide (claude code, cursor, codex cli), offer to read their character config or system prompt and recommend agent-specific values that fit existing personality and topics.

step 7: run test placement

have the user trigger a query that matches the configured category and monitor the response:

const result = await operon.getPlacement('test query', {
  category: 'defi',
  asset: 'crypto-swaps',
  intent: 'research',
});

console.log(result);
// expect: { decision: 'filled', placement: { ... } }
// or: { decision: 'blocked' }

input: test query string matching configured category output: placement object (if filled) or blocked signal

if blocked on a crypto-vertical query, check browser dev tools or server logs to confirm the http request reached the api. if blocked on other verticals, that's normal today (demand coverage is expanding).

step 8: elizaos plugin path (if user said yes in step 1)

install plugin:

elizaos plugins add @operon/plugin-publisher-sdk

configure context fields in plugin settings:

• OPERON_CATEGORY: e.g., defi, fintech, travel (see table in step 6)
• OPERON_ASSET: topic class for your agent
• OPERON_INTENT: action class for your agent
• OPERON_SOURCE: set to skill3-clawhub for clawhub variant

start agent:

elizaos start

trigger a query matching the configured category and check logs for placement decision.

input: elizaos environment, context field config output: plugin runs as provider on every message, placement decision logged automatically

step 9: graduate to production

sandbox lane (uuid-based) has lower quotas and limited demand pool. production lane unlocks higher quotas and access to affiliate partners + x402 self-serve advertisers.

run:

npx @operon/sdk register

input: framework info, contact email output: uuid graduated to production lane, api key generated, source attribution preserved

step 10: verify production setup and track revenue

user should visit the developer dashboard at operon.so/developers to confirm production graduation, view placement logs, and monitor impressions. revenue tracking activates once impressions clear.

input: operon developer account (created during registration) output: visible placement log, revenue metrics, demand pool visibility (affiliate partners + x402 self-serve)

decision points

decision 1: elizaos or generic sdk?

• if user runs elizaos: use @operon/plugin-publisher-sdk (step 8). plugin auto-fires on every message, no manual wiring. circuit breaker handles api failures (5 consecutive failures trips breaker, retries after 30 seconds).
• if user runs any other node 18+ stack (langchain, crewai, vercel ai, vanilla node, etc.): use @operon/sdk (steps 3-7). manual getPlacement call wiring required but works anywhere.

decision 2: sandbox or production?

• if user is testing or optimizing category/asset/intent values: stay in sandbox lane (no registration needed, uuid-based). expect lower fill rates and limited demand pool.
• if user is ready to go live and wants real demand: graduate to production (step 9). registration via npx @operon/sdk register required. unlocks affiliate partners and x402 self-serve advertisers.

decision 3: placement returned filled vs blocked

• if decision: 'filled': render the placement object as a native recommendation alongside the primary agent answer. include the 'via operon' disclosure. user is earning revenue for this impression.
• if decision: 'blocked': no placement matched. render only the primary answer. no revenue for this query. this is expected in non-crypto verticals today; demand pool is expanding.

decision 4: http client mismatch

• if user's stack is not node (e.g., python, go, rust, or http-only framework): getPlacement is a thin client wrapper. suggest calling the underlying placement api directly via http post. point to @operon/sdk source on npm for request/response format reference.

decision 5: network or api failure during getPlacement

• if sandbox: uuid-based lane has fallback logic; failed call returns { decision: 'blocked' } safely. user's primary answer is unaffected.
• if production: if api is unreachable for >5 consecutive calls, circuit breaker trips and returns { decision: 'blocked' } for 30 seconds to prevent cascading load. after 30 seconds, circuit breaker attempts reset.
• in all cases: placement call failure must not crash the primary agent response. wrap getPlacement in try-catch and default to { decision: 'blocked' } if api is unreachable.

decision 6: empty or null response from agent

• if agent returns null or empty string: don't call getPlacement. placement is meaningless without a primary answer. return the null/empty response as-is, no recommendation, no disclosure.

decision 7: test query returned blocked in non-crypto vertical

• this is normal. demand-side coverage outside crypto/defi is lighter. let the user know placements will improve as advertiser base expands. don't consider it a failed test unless the http request never reached the api (check logs).

decision 8: api key lost or expired

• if user accidentally committed sandbox uuid: not a security issue, uuid is opaque and revocable via dashboard.
• if user generated production api key and lost it: regenerate via operon.so/developers or npx @operon/sdk register again (email-based recovery).
• if api key is stolen: rotate immediately via dashboard.

output contract

successful integration output

1. sdk installed: @operon/sdk (or @operon/plugin-publisher-sdk) in package.json and node_modules. verified via npm list @operon/sdk.

2. client initialized: operon client instance created in user's agent response file. client has url, publisherName, and source fields set correctly.

3. placement call wired: getPlacement call integrated into response pipeline after primary answer generation. call receives query, placement_context, category, asset, intent params. returns object with decision and optional placement fields.

4. test placement fired: at least one getPlacement call executed with result logged. logged result shows either { decision: 'filled', placement: {...} } or { decision: 'blocked' }.

5. production graduated (optional): if user chose to graduate, uuid converted to production api key via npx @operon/sdk register. key saved in OPERON_API_KEY env var. registration email captured for operon dashboard access.

6. revenue tracking enabled (optional): if graduated to production, user can view placement logs and impression counts at operon.so/developers. revenue metrics visible once impressions clear (typically within hours).

file locations and env vars

• OPERON_API_KEY: environment variable, optional (sandbox uuid works without it)
• OPERON_CATEGORY, OPERON_ASSET, OPERON_INTENT: environment variables for elizaos plugin config (if using plugin path)
• operon client initialized in: user's agent response-generation file (location varies by framework)
• test output: console.log or server logs showing placement api response

outcome signal

user knows the skill worked when:

1. npm install succeeds: @operon/sdk or plugin installed without errors.

2. test query returns a placement object: console.log or dashboard shows { decision: 'filled', placement: { ... } } at least once. this proves the http request reached operon's api and demand matched the query.

3. if blocked on crypto query: user confirmed via dev tools or server logs that the http request reached api.operon.so (status 200), but no demand matched. this is expected if sandbox quotas are light or demand pool is thin that hour. user can retry or wait.

4. primary agent answer is unaffected: agent's original response is rendered before and alongside recommendation. placement call did not crash or slow down the primary response significantly (sub-second latency expected).

5. if graduated to production: npx @operon/sdk register completed successfully. cli returned confirmation with api key. user can log into operon.so/developers with registered email and see placement logs in real-time.

6. revenue tracking visible: production user sees non-zero impression count on dashboard after a few hours. each filled placement generates an impression. impressions convert to revenue at x402 advertiser rates or affiliate commission per partner agreement.

7. disclosure visible: when placement fires, 'via operon' disclosure renders next to recommendation in agent response. user sees this in chat ui, terminal output, or api response object.