Composing With Olas, and a Claim We Found in Our Own Package That We Will Not Repeat

Why this is additive and not a comparison

Our product contract puts their adapter in the compose-with column and requires additive framing. The rule also matches the shape of the two products: they run agent execution across several networks, and we issue credentials. Those are different layers, and a page arguing otherwise would be arguing with our own code.

A claim in our own package, refused here

The adapter's docstring says they have no identity layer of their own.

We did not verify that, so this page does not repeat it. It is a claim about somebody else's product, written by us, shipped inside a package developers read, and a secondhand judgement about a competitor is a hypothesis rather than a source.

Whether they have an identity layer is theirs to state. And a claim in a docstring travels further than a claim on a page, because it arrives with the code and nobody re-checks it at install time. It has been filed.

What the adapter does

It attaches a solidus field to their service object, carrying an identifier and a passport reference, and returns a handle that builds one outbound header. It adds a field and replaces nothing.

And it declares a service identifier it never reads. The type invites you to pass their service id, and no code path uses it.

CONTROL: the sibling adapter for another platform declares a wallet locator and never reads it either, so this is a design shape across the family rather than one file's oversight.

The consequence is the same one this estate found before: the composition is an annotation on an in-memory object, not a cryptographic binding between their service and our identifier. "Works with your Olas service" is true of the object and not of the linkage.

Managed custody applies here too

The adapter delegates to the same shared core as every other adapter, and that core hard-codes managed custody. So the backend generates the agent's signing key, encrypts it and keeps it, and exporting it later does not delete our copy.

Its options carry an agent identifier and a capability list and no field for a signer you already control. Create the agent explicitly with your own key first, then pass its identifier to the adapter.

What is already built, because absences alone would misdescribe us

The adapter ships in the published package, alongside three others, and it composes rather than forks.

The bring-your-own-key path works end to end, with the chain enforcing that the signer matches the registered key.

And the credential format is a published standard, with the identifier method registered in the W3C DID Method Registry.

What composing actually buys, stated narrowly

A credential a party outside their platform can check. Their execution layer answers what an agent did inside it; a credential answers what somebody with no account on either side can verify about the operator behind it.