Skip to main content

Platform Capabilities

The BOSS Platform has outgrown a simple “workflow + ticket” description. The Go backend (apps/backend) now exposes an opinionated set of domain services, automation hooks, and communication runtimes that work in concert with the Next.js cockpit and the Python agent service. This page captures the functional coverage that already exists in the repository so every contributor understands what the system can do today and which components own each concern.

Organization & Access Fabric​

  • Hierarchical RBAC – pkg/rbac and internal/api/middleware enforce five role levels plus resource/action level permissions. Middleware automatically resolves scope (organization, department, team, resource) before every handler runs.
  • Multi-level org model – internal/service/organization, department, team, and department_function services provide the CRUD, hierarchy views, capacity settings, and manager assignment APIs that power the admin cockpit.
  • Visibility helpers – internal/service/rbac_service.go and the UserContextBuilder middleware hydrate every request with “managed users”, “visible teams”, and other derived sets so downstream services can enforce contextual access without re-querying Mongo.

Workflow, Ticket & Task Fabric​

  • Process definitions and instances – internal/service/process_service.go stores DAG validated processes with phases, task definitions, field schemas, WhatsApp/email presets, and deep-research templates per process.
  • Ticket lifecycle – internal/service/ticket_service.go connects processes to instantiated tickets, applies hierarchical visibility filters, manages watchers, attachments, and audit breadcrumbs.
  • Task workspace – internal/service/task_service.go delivers assignment, dependency tracking, deliverables, threaded comments, evaluations, SLA data, and the hooks the automation layer consumes when tickets/tasks change.

Tool & Automation Engine​

  • Tool registry & executor – internal/tools/registry.go + internal/tools/executor.go load tool descriptors and run implementations (email, WhatsApp, Apollo, CSV processor, deep research, campaign builder, Google Meet scheduler, Plivo calling, etc.).
  • Field mapping & templates – internal/tools/field_mapper.go plus internal/service/tool_template_service.go generate context-aware parameter suggestions, allow per-department presets, and expose template discovery APIs (also used by the Agent Bridge).
  • Permission & auditing – internal/service/tool_permission_service.go and middleware.RBAC lock tool execution down to the task/ticket scope while internal/service/tool_output_service.go normalizes every run for later querying.
  • Cost tracking – internal/service/tool_cost_service.go works with cost_rate_service.go to record LLM/tool usage, convert consumption into USD, and feed the cost dashboards.

Agent Runtime & Automation Loops​

  • Runtime orchestration – internal/service/runtime_agent_service.go proxies to the Python agent runtime with retries, graceful fallbacks, and run polling. Metadata and run logs are persisted through internal/service/agent_service.go.
  • Automation coordinator – internal/service/sales_outreach_service.go listens to ticket+task events, evaluates readiness, and fans out to the sales-outreach runtime agent with ticket/task metadata so automations can act deterministically.
  • Webhook ingestion – internal/api/routes/router.go wires summarization and task-monitoring webhooks; internal/service/summarization_agent_dispatcher.go and task_monitoring_agent_dispatcher.go enrich tickets/tasks with AI updates once those events land.
  • Agent Bridge – internal/api/handlers/agent_bridge_handler.go lets the external Python workflows trigger deep research runs or push email/WhatsApp dispatches securely using the same tool executor and template inventory as human users.
  • Automation options API – /api/v1/automation/options surfaces supported triggers/actions and the currently registered runtime agents so UI workflows can be built dynamically.

Communications & Outreach​

  • WhatsApp runtime – internal/service/gallabox_service.go, whatsapp_session_manager.go, and whatsapp_message_handler.go coordinate Gallabox sessions, maintain per-recipient caches, normalize payloads, and expose history + template/preset endpoints per department/process.
  • Email conversations – internal/service/email_service.go, email_template_service.go, and email_conversation_service.go cover OTP/reset flows, automated notifications, preset libraries, and long-running threaded conversations with summary generation through email_summary_service.go.
  • Voice & call analytics – internal/service/plivo_service.go orchestrates Plivo calls, manages concurrent call limits, streams audio via WebSockets (internal/service/websocket_manager.go), records/transcribes audio through internal/service/transcription, and persists analytics/outcomes in call_analytics_service.go.
  • Scheduler + Google Calendar – internal/service/scheduler handles internal/external availability, conflict detection, and meeting CRUD while internal/service/integration/google_calendar_service.go manages secure OAuth, token storage (encrypted via internal/security/token_cipher.go), and synchronization.

Campaign, Contact & Lead Intelligence​

  • Public lead capture – /api/v1/public/contacts + internal/service/email_service.go let landing pages collect interest and immediately notify the team; campaign tracking hits /api/v1/public/campaigns/traffic so marketing pipelines can push telemetry back in.
  • Campaign builder – internal/service/campaign_service.go generates multi-destination campaigns with automatic UTM tagging, branded short links via link_shortener_client.go, and QR code rendering through qr_code_service.go.
  • Deep research templates – Process-scoped templates (internal/service/deep_research_template_service.go) describe how agent research should be structured per workflow so automations and humans stay aligned.

Analytics, Cost & Intelligence​

  • Cost dashboards – internal/service/cost_insights_service.go plus internal/api/handlers/cost_dashboard_handler.go aggregate per-user/team/department/tool spend with role-aware scope resolution and drill-down APIs.
  • Rates & policies – internal/service/cost_rate_service.go stores rate cards (LLM, phone, WhatsApp, etc.) and exposes administration routes via /api/v1/cost/rates.
  • Tool output intelligence – internal/service/tool_output_service.go normalizes raw outputs into flattened tables, extracts sources/summaries, and offers deep-research history APIs so analysts can query results without re-running tools.
  • Call summaries & transcripts – internal/service/whatsapp_summary_service.go, plivo_summary_service.go, and email_summary_service.go push AI-generated summaries back to tickets/tasks to keep stakeholders in sync.

Knowledge, Content & Docs​

  • Blog/CMS – internal/api/handlers/blog_handler.go, blog_interaction_handler.go, and blog_comment_handler.go power the built-in CMS with likes, bookmarks, nested replies, trending queries, and engagement analytics.
  • Summary templates – /api/v1/summary-templates surfaces per-process summary formats (internal/service/summary_template_service.go) consumed by the AI dispatchers so each department controls how updates look.
  • Timeline enrichment – Activity formatters (internal/service/activity_formatter.go) and audit middleware automatically annotate tickets/tasks with structured events whenever tools, agents, or humans act.

Infrastructure & Observability​

  • Storage adapters – internal/service/storage provides S3, Azure Blob (SAS or shared key), and future storage factories so any tool/service can persist payloads consistently.
  • Audit & compliance – Every request passes through internal/api/middleware/audit_middleware.go, emitting Zap logs with correlation IDs plus RBAC decisions for downstream analysis.
  • WebSockets & streaming – internal/service/websocket_manager.go sends task, tool, and call updates to the cockpit, while internal/service/audio_stream_processor.go handles bidirectional Plivo streams for live AI assistants.
  • AI provider orchestration – internal/ai/manager.go manages Google, OpenAI, and Parallel providers with health checks, fallback order, rate awareness, and per-request overrides so workloads always have a best-effort LLM available.

Where to Go Next​

  • Revisit the Architecture Overview for system diagrams and deployment topology.
  • Explore the REST surface in the API Reference after understanding which capability you need.
  • When planning work, align with the role/agent charters in .codex/roles/ and keep this capability map handy to avoid building duplicate features.