Transpareo in the agentic age

It is just after the end of a shift. The compliance manager exports the shift list from the production system, drops it into her assistant and types one sentence: “Publish product passports for the cells in this list.”

The assistant reads 1240 serial numbers with their batches, asks Transpareo what a passport of this product needs, creates the passports and has them checked against the rules of the regulation. The answer: 1237 ready, 3 not, because one batch is missing its carbon footprint. She supplies the value, the assistant publishes. Two days later the cells leave the plant, each with a QR code that its passport answers under.

This is not a scene from the future: with Transpareo it works today. An assistant handles a compliance task from the request to the signed passport, and the platform hands it everything it needs to know along the way.

Try it right now

Do you have an account with Claude, ChatGPT, Grok or Gemini that is allowed to connect applications? Then connect it to our demo. It is a playground: it rebuilds itself every hour, so whatever you do in it is gone by then.

1. Connect. Add a new application in your assistant, enter https://demo.transpareo.com/mcp as its address and click “Connect”.
2. Approve. Sign in with tester and DemoPass2027 - the credentials are printed here on purpose. The screen that follows names every permission separately. The reading ones you can allow for good; the writing ones are better confirmed one at a time.
3. Ask. Back in the chat window, ask in plain language, something like “Please list our passports.”

A list was requested; the state was read.

What comes back is not only what you asked for but the state it is in. That works because the API hands over more than the lines themselves: how many there are, where they stand in their life, what is missing.

That is the point of this article. The rest explains why it works.

Said and done

Exactly one side had to be connected: the assistant to Transpareo, the three steps above. The other was a file the production system puts out anyway. Nobody set down which column matches which field, nobody maintains an interface: the assistant read the list and wrote the passports, and what it was to do fitted into a sentence. If the list changes, an instruction to the assistant changes, not program code.

Your system needs no new capability for this. It only has to put out what it puts out anyway: the export file, the list from a report, the spreadsheet at the end of a shift.

The same list can be read in by hand. The importer in the application manager takes spreadsheets, names the columns it recognised, checks the run before anything is created and reverts it on request. The result would have been the same. Somebody would just have had to confirm the mapping, read the report and track down the three missing values themselves. An assistant does not change what is possible, it changes how long it takes.

The integration work that used to stand at the beginning of every compliance project now fits into one sentence of plain language.

That is the real shift. Provided the platform at the other end can tell a program what it wants.

Programs were always the main readers

A product passport is rarely read by hand. It is scanned, fetched, checked, passed on and archived, and software does most of that: the retailer’s till, the recycler’s system, an authority’s inspection tool, the importer wanting to know whether a lot is compliant. So most of its readers do not read it with their eyes at all. They read it with a program.

Transpareo is therefore built around its API. Every passport it publishes is a signed, machine-readable document, and the API covers the whole life of one: from a product’s property types through checking and creation to publication and the events of a single item in the field. And it is versioned: anyone building against it today is not building on sand. So what is new is not that programs work with passports. What is new is which programs.

Which is why an assistant’s work does not end at creating them. The same kind of sentence carries through the rest of the life:

• “Recall every passport in batch B-2214.”
• “Add the new carbon figure for lot 88.”
• “Show me every passport that went into repair this month.”

Each of those becomes the same calls a person triggers in the application manager, and leaves the same trail.

An assistant has to be able to ask, not guess

An assistant is a very fast colleague with no prior knowledge of your company. It does what it is told, and it fills gaps with assumptions when it is given no answers. Four things turn guessing into work.

It has to be able to ask what is required. For any product and any granularity, the platform answers which identifiers and properties a passport needs and which of them are already held on the product. For a single item it looks like this:

{
  "identifiers": {
    "batchIdentifier": { "required": true },
    "modelIdentifier": { "required": true, "source": "product", "value": "4006381333931" },
    "serialIdentifier": { "required": true }
  }
}

Two of the three identifiers the assistant has to obtain; the third is already on the product. That is a work instruction, not a guessing game.

It has to be able to check without writing. A check runs the same controls a publication runs and creates nothing. That is exactly where the 1237 to 3 above came from, before anything was published.

It has to understand why something was refused. A refusal names the field and says what to do:

PRODUCT_INVALID: Product invalid
Correct the attributes listed under fields and resend the request.
  brand: Brand needs a brand - none was given
  componentsInput: Components input missing

An assistant reading that adds two values and sends again. One that receives only an error number starts trying things. It is the same wording a person sees at the command line.

It must not lose count. If a connection drops and the assistant tries again, only one passport comes of it, not two. Calls that write carry a key by which the platform recognises a repeat as a repeat.

Every access can be taken back

The more programs work on your data, the more it matters who may do what. Access is created in the application manager and shows its secret exactly once. After that the program works with tokens that expire within the hour, and the secret travels only to the endpoint that issues them. It is kept in the operating system keyring, never in a command-line argument, which would otherwise sit in every process list.

Each access carries precisely the rights you give it: reading is one, writing another, publishing a third, and it can be narrowed down to individual products. Irreversible operations ask for a confirmation on top of that.

When an assistant connects from a browser, a screen appears before approval naming every single permission it asks for. Once granted, the connection is listed on the access page with the name and date of the person who approved it, and it is switched off there too.

Access you cannot take back is not access. It is a key under the doormat.

Your data stays with you

Of its own accord Transpareo sends nothing to an AI provider. What reaches one is what you fetch through your assistant - and which assistant that is, and whether it processes inside the EU, is your decision and not ours. The tool that makes the connection runs on your own machine, and its source is open: your security team can read what it does instead of believing it.

For a European company that is the point that decides it. The platform itself sits in ISO-27001-certified data centres in Germany; where anything goes beyond that is settled by your choice of assistant alone. You can take one that processes inside the EU, or one that never leaves your building: transpareo mcp serves the protocol on your own machine, and which model works behind it is your business.

Then there is what a product passport holds in the first place. As a rule it is product data: serial numbers, batches, materials, measurements. Where personal data is involved after all, your own rules decide who may see it, and the grant can be cut to exactly that: read only, certain products only, switchable off at any time.

Setting it up takes minutes

The same goes for your own workspace, at its own address, such as https://dpp.example.com/mcp: the same three steps, and nothing to install.

Anyone who would rather type, or pour the flows into scripts, takes the command line. transpareo is a single program whose commands are generated from the API description: what the platform can do, the tool can do, without anyone aligning the two by hand. It is open source and lives on GitHub. Three lines: install, log in, see what the access allows.

curl -fsSL https://transpareo.com/cli/install.sh | sh
transpareo auth login --host dpp.example.com --client-id <id>
transpareo me

auth login reads the secret from standard input or from an environment variable, never from an argument, which would otherwise sit in the process list and the shell history. After that the same binary works through the flows:

transpareo dpps requirements --product-id 8 --granularity item
transpareo dpps validate --file passport.json
transpareo dpps create --file passport.json
transpareo dpps publish <code>
transpareo events tail --follow

If an assistant runs on your own machine, one more line connects it:

transpareo setup claude

The same operations are then available as tools, under names that say what they do: dpp_requirements, validate_dpp, create_dpp, publish_dpp, tail_events. What you type at the command line and what an assistant calls are the same thing. There is also a written guide for assistants covering the usual flows, so none of them has to learn the order by trial and error. And anyone who would rather program directly finds the full API description on every workspace under /apidocs.

An assistant costs nothing extra

Nothing extra. An assistant connects as an API consumer, and access for programs is included in every plan. What counts is published passports, not the number of people or programs working on them. Automating compliance work should not arrive as a bill.

The work starts before the obligation

From February 2027 the product passport for batteries is binding, and other product groups follow. The real work is not the passport but getting the product data in order, and that is precisely the work companies are now handing to assistants: gathering fields, finding gaps, chasing supplier data, checking, repeating. How that data reaches the passport at all is described in One stream, one direction; what building your own connection looks like is in the guide to ERP integration.

An assistant that has to guess produces passports that look plausible and do not survive an inspection. An assistant that can ask produces passports that are right. That difference is not made by the assistant. It is made by the platform it turns to.