Technology · Discipline

Vendor-integration reverse engineering

When vendor documentation runs out I probe the platform itself, capture the wire, and compose what actually works.

Auth and access plane, AgentOS, HelixEdge Worker in front of a private tunnelPinned vendor versions
The connector's traffic, read from my edge logs
Discovery probe
Authenticated calls
Key parameter
API hub answers
before any authrenamed from the documented onestale from a cache
  • ≈300lines in the edge Worker built around the connector's real behaviour
  • 20 msaudio pacing the real-time media SDK expects
  • 30 minsoak with a forced mid-call reconnect

A connector learned from the wire

Auth and access plane has to expose private tools to Microsoft Copilot Studio, whose MCP connector behaves differently from its documentation. I decided to learn the connector from my own edge logs and build to what it does, and each undocumented quirk gets explicit handling.

I built an edge Worker around what I found, with two key slots because rotation has to work against a client configuration I do not control. A cache-busting procedure covers the API hub, which can keep returning stale answers from a fixed server.

Discovery probe
Bad token or key
Renamed key parameter
Tool call
probe answeredkey checksprivate tunnel

Coding CLIs pinned to what was observed

AgentOS and Agent Swarm depend on exact behaviours of the vendors' coding CLIs. Each came from watching the tool, and I pinned the versions those behaviours were observed on, so an upgrade is a decision.

Facts learned by watching, pinned to a version
  • One CLI's local socket: how it takes a message
  • Another's app server: a new turn told apart from steering
  • A third's agent-client protocol: a queue notification with a client-chosen prompt id
  • A composer that eats the first Enter after a multi-line paste
Vendor versions over time
observed and pinned herelater releases wait for a decision
Each fact is written beside the code that relies on it.

A media SDK with strict rules

Helix runs on Microsoft's real-time media SDK, which hands out unmanaged audio buffers with strict lifetimes and expects strict pacing. I built the bridge to those rules and soak-tested it, because reconnects and buffer lifetimes only show their faults under fault. See A self-hosted colleague in a Teams call.

One call under soak
paced frames, each buffer released inside its lifetimeforced reconnectpacing resumes

A vendor stack measured before replacing it

The Capabilities model needed a serving stack, and before replacing the vendor's I traced it to its extension point in source, probed it against the model's decoding constraints and measured it in the vendor's own container. See Trying the industrial path first.

The vendor's stack
traced to its extension pointprobed against decodingmeasured in its own container
only then the decision to build a custom one

I modify none of the vendors' products; the work is understanding them precisely and building around them safely.