Live Demo

Enterprises are systems of systems

Each system exposes capabilities, but the meaning lives in schemas, IDs, custom code, and tribal logic. Agents can't safely act across systems by guessing at runtime. Vyuh compiles them into a governed semantic and action graph.

The problem

Hand an LLM raw enterprise APIs and it will confidently hallucinate: invented field names, fuzzy joins across unrelated identifier spaces, fabricated totals, no audit trail. The schemas are too cryptic, the entities don't reconcile, the policies aren't in the spec. Below is what the agent receives without Vyuh — and what it traverses with.

Raw access(without Vyuh)

Schemas, APIs, IDs, custom code — meaning is hidden. Each system is its own island.

Governed capability graph(with Vyuh)

Resolved entities, typed capabilities, preconditions, outputs, policies, and audit traces — one model agents can reason through.

Resolved entities

Typed capabilities

Policies enforced

Auditable traces

The problem

Raw access → confident hallucination

This is what an agent receives without a semantic layer. Pages of fields, cryptic codes, deferred entity sets, undocumented Python. Same business object — three identifier spaces, three schemas, no shared meaning.

Stripe Customer

REST · cus_xxx

{
  "id": "cus_NffrFeUfNV2Hib",
  "object": "customer",
  "address": null,
  "balance": 0,
  "created": 1680893993,
  "currency": "usd",
  "default_source": null,
  "delinquent": false,
  "description": null,
  "discount": null,
  "email": "alex@acme.example",
  "invoice_prefix": "0759376C",
  "invoice_settings": {
    "custom_fields": null,
    "default_payment_method": null,
    "footer": null,
    "rendering_options": null
  },
  "livemode": false,
  "metadata": {},
  "name": "Acme Industries",
  "next_invoice_sequence": 1,
  "phone": null,
  "preferred_locales": [],
  "shipping": null,
  "tax_exempt": "none",
  "test_clock": null
  // ... 60+ more fields, half null
}

Illustrative naive-agent failure

Prompt

Match SAP business partner 17100001 to their Stripe customer.

AGENT

I'll look up the SAP business partner, then search Stripe customers by name.

tool_call: stripe.customers.list(name="Acme Industries")

tool_call: sap.business_partner.get(id="17100001")

OUTPUT

The SAP business partner 17100001 (“Acme Industries”) corresponds to Stripe customer cus_NffrFeUfNV2Hib. Their lifetime value across systems is $847,232.

String-match join. Matched on normalized name — would silently merge two distinct “Acme Industries” tenants in the same system.

Hallucinated total. No tool returned a lifetime value. The number was synthesized from context.

No policy boundary. Agent could read every Stripe customer and every SAP partner. No scope, no audit row, no approval.

These failure modes are the default behavior when LLMs are handed raw OpenAPI / OData specs. Vyuh removes the guesswork by giving the agent typed capabilities, resolved entities, and policies — not raw tool catalogs.

The semantic layer

Live systems compiled into a typed capability graph

Vyuh discovered ACME's SAP S/4HANA, Stripe, and custom Python and built a unified graph: resolved entities, typed capabilities, preconditions, outputs, policies. One artifact agents can reason through.

Capability graph

Loading graph...

SAP modules

Stripe

Custom code

Canonical model

Capability types

Capability spec

1 of 1,164

sap_business_partner:data:get

Fetch a SAP business partner with resolved canonical Customer projection.

Preconditions

scopesap_business_partner:data:read

inputpartner_id: BusinessPartnerId

Outputs

entityCustomer (canonical)

Policies

scoperole must hold sap_business_partner:data:*

piiPII fields redacted unless pii:read granted

Resolves

Customer ↔ Stripe.customer (by tax_id, fallback name+address)

Every capability in the graph carries this structure. Agents plan against preconditions and outputs — not against raw OpenAPI specs.

Initializing demo agent...

Setting up role comparison...