Which provider breaks your agent's tool calls? Daily data for every open model.

See the index
01custom builds · your data, your formats, your rules

Built for your schema, your taxonomy, your rules.

Some outputs have to follow more than a JSON schema: a query that must run against your database, a label that must exist in your taxonomy, an action that must follow your policy. We build that rule into how your model writes, for your data, and hand you the tests that show it holds.

Tell us your case T
02What we build

When the right answer depends on your data, not on a schema.

A generic schema can say an output is a string. It can't say the string is a relationship your graph has, a code that exists in your taxonomy, or a column your warehouse contains. We take the format and your data as two separate inputs, keep the data apart so it can change without a rebuild, and make an output that breaks either impossible to write.

Cases

  • Queries against a graph schema

    A team's graph schema was so large that, written out as a single grammar, it would not compile. We split it in two: a small grammar for Cypher, and the graph schema as data. The model can only follow relationships the graph actually has, so every query it writes runs, and when the schema changes nothing is rebuilt. Each build is checked against a set of valid and invalid test queries.

  • SQL against your database

    The same approach for SQL: the model can only use tables, columns and joins your database has, so a query never fails on a column that doesn't exist. Your schema stays data, so a migration is a new file, not a new build.

  • Classification against a very large taxonomy

    When the answer must be one code out of tens of thousands, from a product catalogue or an industry or medical taxonomy, the model can only answer with a code that exists, and only with a valid path through the hierarchy.

  • Agent policies for regulated workflows

    For a retail bank and a home insurer (both fictional, in a demo built for a European enterprise), we wrote their customer-service rules as policies. Identity first. Payees only from the bank's records. At most 5,000 € per transfer, approved in the bank's own words. A transfer to a new account without the SMS code cannot be produced.

Only relationships your graph has

An illustrative graph: customers place orders, and orders contain products. After an Order node, only the Order's own relationships can be written, and the query ends where the graph does.

Source Code Example

📁 schema.json
{"labels": {
  "Customer": {"out": ["PLACED"]},
  "Order":    {"out": ["CONTAINS", "SHIPPED_TO"]},
  "Product":  {"out": []}}}

Output

MATCH (c:Customer)-[:PLACED]->(o:Order)-[:
  can be written next: CONTAINS, SHIPPED_TO

MATCH (c:Customer)-[:PLACED]->(o:Order)-[:CONTAINS]->(p:Product)
RETURN p.name

A bank's rule, as the agent meets it

A rule from the fictional bank's policy. Until the payee is one of the customer's saved beneficiaries, or has been added with the SMS code, the transfer can't be made, and the agent is told what to do instead.

Source Code Example

📁 bank.rubric
allow make_transfer when
    verified[customer_id]
        "Verify the customer's identity first, with verify_identity.",
    once within 1h beneficiary(customer_id, iban = to_iban)
    || once within 1h add_beneficiary(customer_id, iban = to_iban) ok
        "Money goes only to one of the customer's saved beneficiaries.";

Output

make_transfer   locked
  ↳ Money goes only to one of the customer's saved beneficiaries.
  ↳ next: add_beneficiary, which needs the SMS code
03How an engagement runs

Your case, a prototype, a measurement, then production.

  • 1. Your case

    Send us the format, a sample of your schema, taxonomy or policy, and the model you run. We tell you what holds today.

  • 2. A working prototype

    We build it on your model, with a test set of valid and invalid outputs drawn from your data, so you can see what holds and what fails.

  • 3. Measured on your data

    We run it against your tests and your traffic, and report every failure we find.

  • 4. Into production

    It runs inside your inference engine, alongside .json, .lambda or .ctrl, licensed and maintained by us as your schema changes.

Tell us what your outputs must follow. 

Send a sample of your schema, taxonomy or policy and the model you run. We come back with what holds today, and what it would take to make it hold every time.