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.

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.