AI and external service integration
How AI integrations fit
AI integration uses the same deterministic interfaces as human workflows. BusDK modules expose command-line tools, HTTP providers, event workers, portal surfaces, and workspace datasets so AI automation can be reviewed, repeated, and operated without bypassing module ownership.
For model access, bus-api-provider-llm provides OpenAI-compatible /v1/* proxy routes with Bus authentication, backend header isolation, runtime wake-up, usage capture, and optional billing entitlement checks. For runtime control, bus-api-provider-vm, bus-api-provider-containers, bus-vm, and bus-containers keep VM and container surfaces cloud-neutral while provider-specific work stays in integration workers such as bus-integration-upcloud and bus-integration-ssh-runner.
Agentic workflows are separate from the model proxy. bus-agent, bus-dev, bus-run, and bus-work provide local and durable work surfaces for prompts, tasks, scripts, and event-delivered work. These tools can read structured workspace datasets, run the same CLI workflows as a human, and propose changes as reviewable updates to repository data.
Product operation adds another layer. bus-auth, bus-billing, bus-events, bus-api-provider-usage, bus-integration-billing, bus-integration-stripe, bus-integration-usage, and the bus operator modules cover authentication, scoped service tokens, billing setup, entitlement checks, usage collection, catalog operations, and payment-provider integration.
BusDK remains usable without model automation. Accounting, reporting, validation, and filing modules still operate through deterministic CLI and dataset contracts. The AI-specific modules extend the platform for hosted or self-hosted AI products rather than replacing the human-operable workflows, consistent with AI-readiness, Git as source of truth, and Deployment and data control.