Autonomous Catalog and Negotiation Agents on ONDC

ONDC is designed to make digital commerce interoperable: buyers can discover sellers across applications, while sellers can reach customers through multiple buyer networks. The next major opportunity is to add intelligent software agents that can understand product catalogs, compare offers, negotiate within approved rules, and complete transactions across the protocol.

Autonomous catalog and negotiation agents on ONDC are not simply chatbots connected to a shopping site. They are policy-controlled systems that combine catalog intelligence, protocol integration, business constraints, and transaction-level decision-making. For Indian startups, this architecture can reduce the cost of commerce operations while helping small sellers compete on discoverability, price, service, and personalization.

What Are Autonomous Catalog and Negotiation Agents on ONDC?

An autonomous catalog agent converts structured and unstructured seller information into reliable, searchable commerce data. It can ingest spreadsheets, images, invoices, product descriptions, regional-language content, inventory feeds, and logistics details, then produce normalized catalog attributes suitable for ONDC-compatible buyer and seller applications.

A negotiation agent operates on top of that catalog and transaction layer. It evaluates a buyer’s request against policies such as:

Minimum acceptable selling price
Inventory availability and replenishment forecasts
Customer segment and order history
Delivery location and fulfilment cost
Payment, return, and cancellation rules
Promotion budgets and campaign limits
Seller margin and tax requirements

The agent may recommend or execute actions such as suggesting a bundle, applying an approved discount, offering a different delivery slot, proposing a substitute product, or declining a request outside the seller’s rules. The key distinction is controlled autonomy: the agent can act independently, but only within explicit commercial and compliance boundaries.

Why ONDC Is a Strong Environment for Commerce Agents

Traditional e-commerce often concentrates demand, seller access, and customer data inside a single platform. ONDC separates network participation from the consumer-facing application. This creates a more open environment in which specialized agents can support different parts of the commerce journey.

Potential benefits include:

Interoperable discovery: Agents can help buyers find relevant products across participating network roles.
Seller portability: Catalog intelligence can support sellers that operate through more than one buyer or seller application.
Lower operating costs: Automation can reduce manual listing, catalog correction, and customer-support work.
Better regional reach: Language models can generate and validate content in Indian languages and English.
Richer product comparison: Agents can compare price, delivery promise, quality signals, seller policies, and total landed cost.
Programmable offers: Negotiation can become a rules-based process rather than an ad hoc discount conversation.

ONDC does not eliminate the need for protocol compliance. Agents must still work with the relevant network specifications, participant roles, transaction flows, authentication mechanisms, and operational requirements. The intelligence layer should complement—not bypass—the network protocol.

Core Architecture

A production-grade system generally requires six layers.

1. Data ingestion and catalog normalization

The platform collects product data from seller systems, point-of-sale tools, ERP software, CSV files, images, and manual uploads. It then maps inconsistent fields into a canonical schema.

For example, a grocery seller may describe the same product using different units: “1 kg,” “1000 g,” or “one kilo.” The normalization service should standardize quantity, unit, pack size, brand, category, dietary attributes, and applicable restrictions. It should also distinguish product variants from separate products.

Useful components include:

Schema mapping and validation
OCR for labels and invoices
Image classification and attribute extraction
Duplicate detection
Unit and currency normalization
GST and HSN-related data validation where applicable
Regional-language translation and transliteration
Human review queues for low-confidence records

2. Product knowledge graph and search index

A simple keyword index is insufficient for agentic commerce. The system should represent relationships among products, variants, brands, categories, seller policies, substitutes, complementary items, and fulfilment locations.

A hybrid retrieval architecture is usually effective:

Relational storage for transactional and inventory facts
Search indexes for exact filters and ranking
Vector databases for semantic retrieval
Knowledge graphs for product relationships and constraints
Event streams for price, inventory, and order updates

The agent should never rely solely on generated text to answer factual questions. Price, stock, delivery promise, refund policy, and product specifications must be retrieved from authoritative systems at decision time.

3. ONDC protocol adapter

The protocol adapter translates internal agent actions into valid ONDC network messages and converts responses into internal objects. It should isolate protocol-specific logic from the reasoning engine.

A robust adapter typically handles:

Participant and role configuration
Request and response validation
Correlation of transaction IDs and message IDs
Search, selection, initialization, confirmation, status, and cancellation flows
Error handling and retry policies
Signature, authentication, and secure transport requirements
Version compatibility and schema evolution

Do not allow a large language model to construct production protocol payloads without deterministic validation. The model can select an intent or propose a transaction, but a typed service should generate and validate the final message.

4. Policy and negotiation engine

The negotiation engine should combine deterministic rules with optimization. Deterministic rules protect the business; optimization helps choose the best permissible action.

A seller policy might look like this:

If cart value >= ₹2,000 and gross margin after delivery >= 18%:
    offer free delivery
If stock cover < 3 days:
    do not offer additional discount
If customer requests a substitute:
    allow only same-category products within 10% of price
If requested price < floor price:
    decline and show the best approved bundle

The engine can use mathematical optimization for objectives such as margin, conversion probability, delivery cost, or inventory clearance. It should expose the reason for every decision, including the policy version, input facts, and approval level used.

5. Agent orchestration and tool use

The agent should be designed as a workflow, not an unrestricted autonomous persona. Typical tools include:

Catalog search
Inventory lookup
Price and promotion calculator
Logistics quote service
Tax and invoice service
Customer eligibility checker
ONDC transaction adapter
Human approval service
Audit-log writer

A state machine or durable workflow framework is preferable for long-running commerce transactions. Each step should be idempotent, observable, and recoverable after timeout or network failure.

6. Observability, governance, and human oversight

Commerce agents require stronger controls than ordinary customer-support bots. Store structured logs for every recommendation and action:

Input request and user identity context
Products and offers retrieved
Policy rules evaluated
Tools called and returned values
Agent confidence and uncertainty
Final action and responsible system version
Human override, if any

Dashboards should track negotiation acceptance rate, discount leakage, gross margin, cancellation rate, catalogue errors, protocol failures, latency, and complaints by language or geography.

Catalog Intelligence: From Listing Automation to Commerce Readiness

Catalog quality is a foundational constraint. An agent cannot negotiate accurately if the product data is incomplete or contradictory. A commerce-ready catalog should include more than title, price, and image.

Important fields may include:

Product and variant identifiers
Brand, category, and attributes
Pack size, dimensions, weight, and unit
MRP, selling price, tax treatment, and discounts
Stock quantity and fulfilment location
Delivery areas and estimated timelines
Return, replacement, warranty, and cancellation policy
Dietary, safety, age, or regulatory attributes where relevant
Language-specific title and description
Image quality and accessibility metadata

The agent should assign confidence scores to extracted fields. For example, a model may be highly confident that an image contains a blue shirt but uncertain about fabric composition. High-risk fields must go to human review rather than being silently invented.

For Indian sellers, multilingual catalog generation is valuable but requires careful localization. Translating “organic,” “handloom,” “pure,” or “natural” can create misleading claims if the underlying certification or evidence is absent. Generation systems should preserve approved claims and flag unsupported marketing language.

How Negotiation Agents Should Work

Negotiation on ONDC should be understood as constrained offer selection, not unrestricted bargaining. The buyer’s request may concern price, delivery, quantity, bundle composition, payment method, or substitution. The agent evaluates the request against seller economics and network capabilities.

A typical flow is:

1. Parse the buyer’s intent and constraints.
2. Retrieve current catalog, price, stock, logistics, and policy data.
3. Identify eligible products or sellers.
4. Calculate total cost, including delivery and applicable charges.
5. Generate permissible offers or alternatives.
6. Rank options by the configured objective.
7. Present the offer with clear terms and expiry.
8. Obtain confirmation before creating or modifying a transaction.
9. Log the decision and monitor fulfilment.

Offers should have explicit validity periods. A discount calculated against stale inventory or an expired campaign can cause disputes. If the agent cannot verify a fact, it should ask for clarification or defer to a human operator.

Recommended Technology Stack

A practical implementation may use:

Backend: Java, Go, Python, or TypeScript services
Data: PostgreSQL for transactional records; OpenSearch or Elasticsearch for filtering; a vector store for semantic retrieval
Messaging: Kafka, RabbitMQ, or cloud queues for inventory and order events
Workflow: Temporal or an equivalent durable orchestration layer
Models: A compact language model for classification and extraction, with a stronger model for complex reasoning where justified
Validation: JSON Schema, typed SDKs, contract tests, and protocol conformance tests
Security: Key management, encryption, role-based access control, secrets rotation, and tamper-evident logs
Monitoring: OpenTelemetry, centralized logs, metrics, tracing, and alerting

Use retrieval-augmented generation only for tasks that benefit from language understanding. Pricing, inventory, tax, and eligibility should come from deterministic services. This separation reduces hallucinations and makes audits practical.

Security, Privacy, and Responsible Autonomy

An agent that can alter prices or confirm orders is a high-impact system. Threat modeling should cover prompt injection in product descriptions, malicious seller content, fake inventory, unauthorized discounts, account takeover, replayed messages, data exfiltration, and tool misuse.

Controls should include:

Treat catalog text and buyer messages as untrusted input.
Keep system instructions and business policies separate from retrieved content.
Use allowlisted tools with strict schemas and permissions.
Require confirmation for irreversible or high-value actions.
Apply spending, discount, and order-value limits.
Protect personal data and collect only what is necessary.
Define retention and deletion policies for buyer and seller information.
Test for discriminatory ranking or unfair offer allocation.
Provide a clear escalation path and accessible human support.

Indian deployments should account for the Digital Personal Data Protection Act, 2023 and applicable sectoral obligations. Legal review is essential because responsibilities may differ among sellers, applications, network participants, logistics providers, and technology vendors.

Business Models for Indian Startups

There are several viable routes to market:

Seller SaaS: Charge sellers for catalog automation, pricing, and negotiation tools.
Enterprise integration: Integrate with retailers’ ERP, POS, CRM, and inventory systems.
Agent infrastructure API: Provide catalog intelligence, ranking, or policy APIs to ONDC participants.
Vertical solution: Focus on grocery, fashion, handicrafts, B2B supplies, mobility, or services.
Managed commerce operations: Combine software with catalog and customer-support services for small businesses.
Performance pricing: Charge based on orders, gross merchandise value, or measurable automation savings.

Start with a narrow vertical. Product attributes, buying behavior, margins, and negotiation logic differ sharply between fresh produce, apparel, electronics, and business procurement.

Implementation Roadmap

Phase 1: Establish data and protocol foundations

Select one category, define a canonical product schema, connect inventory and pricing, and implement a validated ONDC adapter. Measure catalog completeness and transaction success before adding autonomy.

Phase 2: Add recommendation and assisted negotiation

Let the agent suggest products, bundles, and offers to a human operator. Capture overrides and outcomes to improve policies. This phase creates training data without exposing the business to uncontrolled decisions.

Phase 3: Automate low-risk decisions

Enable autonomous actions for approved discount bands, substitutions, delivery-slot changes, and routine catalog corrections. Use thresholds for order value, margin, customer risk, and confidence.

Phase 4: Optimize network-wide performance

Introduce experimentation, demand forecasting, seller segmentation, multilingual experiences, and portfolio-level optimization. Keep a rigorous holdout strategy so that conversion gains are not confused with margin destruction.

Metrics That Matter

Track both commercial outcomes and system reliability:

Catalog attribute completeness and correction rate
Search relevance and product-match accuracy
Offer acceptance and conversion rate
Incremental gross margin after discounts
Average order value and repeat purchase rate
Delivery promise accuracy
Cancellation, return, and complaint rates
Percentage of transactions completed without human intervention
Agent tool-error and protocol-failure rate
Median and tail latency
Cost per assisted or autonomous order
Number and severity of policy violations

A successful agent is not the one that negotiates the lowest price. It is the one that improves customer and seller outcomes while preserving trust, margin, compliance, and operational control.

Common Failure Modes

Treating the language model as the system of record

Models are useful for language and reasoning, not authoritative stock or price data. Always retrieve live facts from transactional services.

Automating before catalog cleanup

Poor attributes lead to incorrect matching, misleading offers, and avoidable cancellations. Invest in normalization and review workflows first.

Using one policy for every seller

A local artisan, a national brand, and a wholesale distributor have different margins and service constraints. Make policies configurable and versioned.

Ignoring protocol and operational edge cases

Timeouts, duplicate callbacks, partial failures, cancellations, and status mismatches are normal in distributed commerce. Test them explicitly.

Optimizing conversion alone

Discount-heavy agents can increase orders while destroying contribution margin. Optimize a balanced objective that includes profitability, fulfilment quality, and customer trust.

FAQ

Can a negotiation agent change the seller’s price automatically?

Yes, if the seller explicitly authorizes it through versioned rules, price floors, discount limits, and approval thresholds. High-value or exceptional offers should require human confirmation.

Does ONDC provide an AI agent by default?

ONDC is an open network and protocol ecosystem, not a single autonomous-agent product. Startups can build intelligent services that operate for sellers, buyer applications, or other network participants while meeting applicable requirements.

Are autonomous agents suitable for small Indian sellers?

They can be, especially when delivered as a managed SaaS or embedded service. The best starting points are catalog cleanup, multilingual listing creation, inventory synchronization, and low-risk offer automation.

How can hallucinations be prevented?

Use retrieval from authoritative systems, typed tool calls, schema validation, deterministic pricing services, confidence thresholds, and human review for uncertain or high-impact actions.

What should founders build first?

Start with one category and a measurable workflow such as catalog normalization or margin-safe offer recommendations. Prove data quality and transaction reliability before enabling broader autonomy.

Apply for AI Grants India

Building autonomous catalog and negotiation agents on ONDC can create infrastructure for more inclusive, efficient Indian commerce. If you are an Indian AI founder developing a protocol-aware commerce product, apply to AI Grants India for potential support and visibility.