Buffaly integrations and surfaces

Surface types

• The chat surface is where users ask for outcomes and review progress.
• Sessions and timelines hold ongoing work, conversation turns, tool calls, and progress evidence so prior decisions remain reviewable.
• Wiki documentation is the durable human-facing explanation surface for how Buffaly works, how to operate it, and how to extend it.
• Web modules provide visual flows such as browser work, voice, local runners, or specialized configuration.
• Services, providers, and tools expose typed back-end capabilities that Buffaly can discover and call.

Core web-module families are Wiki, Sessions, Browser, ComputerUse, DesktopViewer, SkillManagement, Heartbeat, and RealtimeVoice. Developer surfaces include CodeReviews, OntologyWorkbench, CodexEmbedded, and SourceViewer. Optional packages (Google Workspace, Office 365, ads, Feeding Frenzy) are not stock product. The classified list is on Web modules and UI. Installed LLM providers are OpenAI, OpenRouter, Anthropic, Gemini, xAI, LlamaCpp, and Ollama when those modules are enabled.

Choosing a boundary

• Use the wiki for durable explanations, memory for reusable facts and workflows, and secrets for protected credential values.
• Use tools and actions for concrete executable operations that need a callable interface.
• Use a provider when the integration supplies models, embeddings, or transport/authentication for AI calls.
• Use a service when identity, lifecycle, shared configuration, or method projection matters.
• Use a web module when a user needs an interactive UI or visual verification surface.

Integration checklist

Before adding or troubleshooting an integration, make the user path and validation signal explicit.

• Name the surface a user will touch: chat, provider setup, service action, web module, or external system.
• List required credentials, routes, settings, and approval boundaries before testing.
• Run one small happy-path check and one expected failure check so diagnostics are easy to locate.
• Record where evidence should appear, such as the UI, logs, provider response, service diagnostics, or session artifacts.

Operating expectations

• Document required credentials, settings, routes, and validation tasks for each integration.
• Make error locations clear: UI message, logs, provider response, service diagnostics, or session artifacts.
• Keep user approval boundaries explicit for actions that access external systems or sensitive data.