Platform scale: ~5M estimated lifetime contact records
Client installations built on my platform have managed approximately 5 million lead, subscriber, and customer records over their lifetime (estimated).
The supplied database-check summary reports 2,087,071 verified contact records across 187 client installations, excluding our own platforms.
Approximately 5 million is the upper end of the supplied 3–5 million lifetime estimate, not a verified total. The estimate allows for closed or unreachable client sites, including assumed audiences for 387 historical sites with recorded sales whose contact counts could not be measured.
Records include leads, subscribers, and customers. A person can appear on several sites, and some contacts were imported. These counts do not establish unique people, paying customers, simultaneous active users, or contacts generated by the AI agent. Source: the owner's supplied database-check screenshot. The underlying calculation and queries were not included in the attachment, and this workspace has not independently rerun the count. These platform-wide lifetime figures are separate from the AI-agent audit below.
View the supplied source summaryThe problem
Entrepreneurs have an idea for a business, but turning it into pages, content, funnels and connected settings requires a lot of coordination
OctoFunnel makes those resources accessible through one virtual project filesystem. The built-in AI agent and MCP-connected agents can inspect and change the actual workspace from a customer’s request. The customer can then continue editing the same resources visually
Reduce the navigation, translation and handoff work between a business idea and a usable project. The implementation and usage are observable; the amount of customer time saved still needs a matched benchmark
The architecture
A small, stable tool interface over a rich domain model
Both agent entry points use one virtual filesystem
The built-in AI agent and MCP-connected agents share the same workspace tools, contextual instructions and validated business data
The activity totals below combine recorded tool calls from both agent entry points
9 shared filesystem operations
Both agents navigate, inspect and modify business resources through the same tool executor. Contextual instructions and validated document views keep domain rules close to the work
Agent and human edit the same work
For example, an agent-friendly YAML website view maps to canonical JSON entries. The admin builder and public renderer use that data. Derived views do not require a duplicate AI-owned project
The engineering decisions
Instructions follow the current task
Navigation attaches the applicable README. A server-side version and call-lag mechanism refreshes instructions and state when the external host’s context may be stale
Validate before committing
The shared VFS routes changes through domain guards. Folder-aware write/edit gates require applicable instructions in context; authorization resolves server-side project permissions
Keep work observable through interruption
Built-in chat persists turn identity, steps and terminal status. Generation jobs separate interruption counters from execution failures and retain recovery state
Support visual editing throughout
The customer can inspect and revise saved resources without an import step. Selected content trees publish on save, with the tradeoff that validation and permissions must protect live changes
Benefits here describe implemented mechanisms. They do not imply a measured reduction in tokens, support requests or elapsed customer time
Measured results
One view of agent activity across the built-in AI and MCP, operating through the shared virtual filesystem
| Measure · 8 Sep–7 Oct 2026 | Observed result | Definition |
|---|---|---|
| Active customer-cohort owner accounts | 113 | Chat or MCP activity, deduplicated by project owner; 111 accounts had recorded tool activity |
| Recorded AI agent tool calls | 39,592 | Workspace tool calls from both agent entry points across 115 projects, including reading, navigation and orientation |
| Tool-call success | 89.36% | 35,380 successful technical results from 39,592 recorded calls |
| Successful modification calls | 8,608 | 72.01% of 11,954 write, edit, copy, move or delete attempts; calls can repeat or make no effective change |
| Repeat-day activity | 69 / 113 | 61.1% active on two or more distinct dates within the same window |
Download the verified agent activity aggregates
Customers use both agent entry points to operate the same project workspaces. The records demonstrate tool execution, including modification calls; customer acceptance and time saved require separate measurement
Data sources and measurement boundaries
The total combines 24,706 built-in agent tool-result rows and 14,886 MCP call records. Successful modification calls combine 5,116 built-in results and 3,492 MCP results. Built-in success follows the executor’s non-error result convention; MCP uses its recorded success flag. Six setup-only navigation markers and one unsupported tool request were excluded, and replay-event copies were not added
The customer cohort is a provisional project-owner classification after configured operator and test-like email exclusions and may include staff assistance. Counts describe retained records verified on 9 October 2026; logs can be incomplete or deleted. Visual browser-agent actions cannot be attributed reliably from ordinary admin requests. Technical success does not establish unique changes or customer acceptance
Reliability and lessons
Several safeguards are implemented below the prompt layer: domain validation, server-side access checks, revision-aware writes, bounded restorable checkpoints and durable reply records. MCP callers receive execution results that let the model respond to rejected operations
Authorization and durable turns
Six focused tests passed across member-token authorization and durable-turn recovery. These verify selected behaviors, including role changes, removed membership, Stop fencing and terminal-state handling
Verification is deliberately scoped
Two additional selected checks failed: a context-refresh expectation disagrees with the current contract, and a media-read assertion expects a missing label. The full application suite was not run for this research
Across all four selected files: 7 tests passed and 2 failed. Tests use the inspected source snapshot; this is not a claim about full production safety or overall test coverage
Lessons from the implementation
- One registry prevents interface drift. Prompts and MCP descriptors derive their tool names from the same source
- Context management needs server logic. An external host can lose instructions; folder context and refresh behavior are explicit parts of the protocol
- Process restarts are not model failures. Separate interruption and failed-attempt counters keep those failure modes distinguishable
- Telemetry needs semantic review. In-app “completed” includes deliberate user stops, so it must not be advertised as answer success
The next result to prove
Measure time to an accepted result across manual UI, browser-agent and MCP-assisted workflows
Use matched briefs for a landing page, a three-message funnel, an offer update and a configuration repair. Predefine acceptance, counterbalance task order, and measure total elapsed time, human effort, review/rework, failures and interventions. Record browser-agent attribution explicitly
A successful benchmark should support a statement about equivalent accepted deliverables, with the sample size and failure rate beside the time-saving estimate. No speedup percentage is claimed before that evidence exists
Technical references
Production aggregates: initial read-only PostgreSQL audit on 8 October 2026; combined built-in AI and MCP tool activity verified with read-only queries on 9 October 2026. Window: 8 September 00:00 through 8 October 00:00 UTC, end exclusive. Implementation: monorepo source snapshot 3b91d462f. No customer identities or raw conversations are reproduced
- S1 · Tool interface
packages/vfs/src/tools.ts:42; packages/mcp/src/contract.ts:42
Nine VFS verbs plus MCP-only orient; registry-derived interfaces - S2 · One data model
apps/server/src/agent/vfs-bind.ts:485; packages/vfs/src/site-yaml-view.ts:1
Production VFS factory; YAML views over canonical JSON entries - S3 · Context management
packages/mcp/src/sections.ts:114; packages/vfs/src/folder-readme-gate.ts:40
Version and call-lag refresh; folder-instruction gate for write/edit - S4 · Guarded changes
apps/server/src/agent/vfs-permissions.ts:97; packages/vfs/src/vfs.ts:1184; packages/vfs/src/checkpoints.ts:21
Server authorization mapping, revision-aware writes, bounded restorable checkpoints - S5 · Durable work
packages/db/src/schema/ai-chat.ts:149; apps/server/src/agent/durable-turn.ts; packages/db/src/schema/funnel-gen.ts:27
Idempotent reply turns; durable generation records separate interruptions from failed attempts - S6 · Attribution and recording
packages/db/src/schema/mcp-call.ts:1; apps/server/src/mcp/session-store.ts:306; apps/server/src/agent/loop.ts:1621; apps/server/src/routes/ai-chat/route.ts:1745
MCP per-call records and built-in agent tool-result rows; shared VFS execution; separate browser-agent attribution limits - S7 · Result semantics
apps/server/src/routes/ai-chat/route.ts:2050; packages/db/src/schema/ai-chat.ts:151
Completed status can include a deliberate Stop; tool calls are distinct from user-accepted outcomes