The source doesn't specify the implementation language for the UI extension itself, though the build tooling (yarn, React peer dependencies) hints strongly at TypeScript/JavaScript on the frontend. For the backend integration, the source only says it speaks "a single generic provider"—the OpenAI-compatible chat completions API—without detailing how query context (manifest, events, logs) is *constructed* or *routed* to the LLM. On "tool doors" or tool abstraction: the source doesn't mention those concepts or any agentic tool-use framework at all. It describes a *context-enrichment* pattern—the extension gathers resource data and feeds it into a single completions endpoint—but doesn't reveal whether it uses structured tool definitions, function calling, or any form of agent scaffolding. It's possible the LLM is just given a formatted text prompt with the resource and events as context, or the backend could implement OpenAI's function-calling extensions transparently. The source is silent on this. The deployment and development docs are linked but not included here, so they might answer the architecture question more precisely. You'd want to check `docs/` or the proxy extension integration for the actual query-building logic.