AI Agent Orchestration Workspace

floffi keeps AI work reviewable, recoverable, and operable.

floffi is an AI agent orchestration workspace for creating, executing, reviewing, and operating multi-step agent work. This page is a browser-friendly landing preview of the public README, served by the same Go app as the product.

Why it mattersShows orchestration complexity across auth, tenancy, workflow state, webhooks, notifications, persistence, and search.

What it provesAgent output can be structured into explicit review, rollback, restore, and operator-facing control paths.

Who it is forHiring managers and engineering leads scanning for evidence of end-to-end product ownership.

Why This Project Exists

Most AI applications solve a single request. floffi explores the harder problem: how to keep AI work operable inside a real product.

Users create or receive work inside a workspace
Agents hand off tasks across explicit workflow stages
Results go through a boss inbox instead of being blindly accepted
Rejected or failed work can be rerun, rolled back, or restored safely

Why This Is Hard

Reviewable AI output

LLM results are nondeterministic
Approval, rejection, rerun, and restore need first-class paths
Human review must be part of the product model, not an afterthought

Recoverable workflow state

Task execution and report generation mutate shared state
Save failures cannot leave the UI ahead of persistence
Restore behavior has to survive partial workflow changes

Workspace isolation

Personal bootstrap and shared workspaces coexist
Invitations, membership changes, and owner transfer must stay consistent
Tenancy boundaries affect auth, switching, and operator flows

Operational ingestion

Work can enter through webhook-triggered workflow creation
Notifications and provider keys need stable operator-facing paths
Search and persistence must support long-lived workspace state

Engineering Decisions

Boss review is not just a status column

AI output is treated as reviewable work, so approval, rejection, rerun, and restore are modeled as explicit product flows.

Workspace isolation is part of the product model

Tenancy is built into auth, membership, workspace switching, and owner/admin flows rather than bolted on after the board UI.

Rollback matters as much as execution

Review actions and restore flows are designed so persistence failures do not silently leave interface state ahead of stored state.

Frontend complexity is decomposed intentionally

Hooks and split panels keep orchestration behavior evolvable without turning one top-level component into the entire product.

Architecture At A Glance

The system is organized as one product surface: a React workspace UI on top of a Go API, with auth, workspace tenancy, workflow and review logic, webhook ingestion, LLM provider abstraction, and SQLite-backed persistence.

Client and API

The React workspace UI talks to a Go HTTP API that owns auth, workspace, workflow, and operator-facing product behavior.

Core domain

Workspace tenancy, workflow execution, boss review, restore flows, and webhook ingest are handled as connected domain paths rather than separate demos.

Persistence

Auth, sessions, and workspace metadata live in SQLite, while attachments are stored on the filesystem as durable product state.

Integrations

Workflow execution fans out to LLM providers through one abstraction layer and can receive work through webhook ingress or emit outbound notifications.

React Workspace UI
↓
Go HTTP API
↓
Auth / Workspace / Workflow / Review / Webhook
↓
SQLite + Filesystem
↓
LLM Provider Abstraction + Notifications

Core Product Flows

The product is easiest to understand as four connected flows: agent handoff on the board, boss-gated report review, repeatable runbook-style operations, and webhook/notification-driven intake.

Authenticate into a personal or shared workspace and enter an isolated operating context.
Create work manually, trigger it from a runbook, or ingest it through a webhook entrypoint.
Move tasks across agent-owned workflow stages on the kanban board while preserving operator visibility.
Land generated output in the boss inbox so approval, rejection, rerun, and restore remain explicit review actions.
Persist workflow state, notifications, search context, and review decisions back into the workspace model.

Representative Demo Visuals

These visuals are actual captures from a seeded floffi workspace, so the preview reflects the implemented product UI rather than an illustrative mockup.

Animated workflow reel for floffi — End-to-end workflow reel that ties together task creation, agent handoff, boss review, and searchable operating context.

Task creation and auto assignment — Task creation and auto-assignment start point: the operator chooses the initial team, assignee, and whether the task begins as a single run or a workflow.

Workflow board — Workflow progression surface: the kanban board shows where work starts, which stage currently owns it, and how agent handoff stays inspectable.

Boss inbox actions — Boss inbox gate: generated output is not auto-accepted, and approve or request-revision remains an explicit operator decision.

Full report review modal with the complete generated body, export path, and rerun-oriented controls before the workflow advances or closes.

External operations and context surfaces: webhook-driven intake, notification-aware operator flow, and searchable vault or memory context after execution.

Workspace switcher — Supporting tenancy and collaboration surface with personal or shared workspaces, membership context, and workspace switching.

Login and security view — Supporting security surface with login, MFA, and session-oriented account controls.

How The System Stays Operable

Frontend decomposition

Large UI control flow was split into focused hooks and panels instead of leaving orchestration logic in a single oversized component.

Failure-path rollback

Boss review actions roll back local UI state when persistence fails, reducing drift between the interface and stored workspace state.

Persistence discipline

Workspace saves use concurrency-aware patterns and recovery paths instead of naive overwrite-only updates.

Regression coverage

Workflow state, report handling, and restore paths are defended by regression tests after review-driven findings.

System Shape and Entry Points

System shape

Backend: Go HTTP server and Cobra CLI
Frontend: React 19, TypeScript, Vite, Tailwind CSS
Workspace persistence: SQLite plus filesystem-backed attachments
Security: JWT, refresh sessions, email verification, TOTP MFA
LLM provider abstraction: Gemini, OpenAI, Anthropic via server keys or BYOK
Validation: tests, production build, TypeScript no-emit checks

High-signal code entry points

internal/server/auth
internal/server/workspace.go
internal/server/workspace_membership.go
internal/server/webhook.go
frontend/src/hooks/useWorkspaceFlow.ts
frontend/src/hooks/useWorkspacePersistence.ts
frontend/src/hooks/useTaskActions.ts
frontend/src/hooks/useReportActions.ts

Quick Start and Validation

This is the shortest path to running and validating the public branch locally.

npm --prefix frontend install npm --prefix frontend run build go run ./cmd/floffi serve

go build ./cmd/floffi npm --prefix frontend run build npm --prefix frontend exec tsc --noEmit

Portfolio Framing

floffi is an AI agent orchestration workspace that treats orchestration as a real product problem. The engineering value is in making agent-driven work reviewable, recoverable, and operable across auth, tenancy, workflow review, integrations, and persistence.