GrowQR End-to-End System Flow

A linear view of how a user request moves through the product: from interactive client, through auth and durable agent orchestration, into sandboxed execution, domain tools, versioned memory, and back to the UI.

Client / Gateway Durable Control Runtime Execution Domain Tools Versioned Memory System DB
1

User Interaction

User opens a channel, thread, quest, or agent module.

  • Chat-first interface
  • Generated UI cards
  • Realtime progress surface
2

Gateway Bootstrap

Stateless backend validates identity and prepares the session.

  • Auth/session verification
  • Billing/entitlement checks
  • Repo + actor lookup
3

Actor Connection

Client connects to the durable control plane for live orchestration.

  • WebSocket event stream
  • Actor key routing
  • Per-user state hydration
4

Intent Routing

The control plane maps intent to a thread, quest workflow, or specialized agent.

  • Thread/session state
  • Quest workflow state
  • Runtime lifecycle decision
5

Sandbox Startup

An isolated execution environment is created or resumed.

  • Per-user/runtime isolation
  • Workspace/worktree mount
  • Agent harness session
6

Agent Execution

The runtime performs reasoning, tool selection, file operations, and progress streaming.

  • Sub-agent delegation
  • File/read/write/bash tools
  • Incremental UI events
7

Domain Tool Calls

Existing services are invoked as controlled tools, not as direct frontend destinations.

  • Interview / Roleplay
  • Pathways / Q-Score
  • Social & matching tools
8

Memory Commit

Outputs become versioned memory and indexed system metadata.

  • Markdown/JSON memory files
  • Diff, commit, merge
  • DB pointers + indexes

Request Path

Initial
Client calls the gateway for auth, provisioning, and actor connection details.
Realtime
Client then communicates with the durable control plane over live events/actions.
Return
Progress, tool activity, generated UI modules, and final artifacts stream back to the client.

Control Responsibilities

Actors
Hold small durable state: active threads, quest runs, runtime handles, recovery pointers.
Workflow
Serialize long-running work, resume after restarts, coordinate runtime and memory commits.
Security
Control which user, actor, runtime, repo, and service calls are allowed.

Execution & Persistence

Runtime
Ephemeral sandbox runs the agent harness and tool execution. It can be killed/restarted.
Memory
Git-backed files are the durable user memory and audit trail.
DB
Relational storage keeps product metadata, indexes, recovery pointers, and billing/account records.

Why actors?

They provide durable, addressable entities for users, threads, quests, runtimes, and score updates without rebuilding locking and recovery in the gateway.

Why sandbox?

Agent execution can run file tools, shell commands, plugins, and service calls in an isolated, disposable runtime.

Why Git memory?

User context becomes inspectable, versioned, diffable, reversible, and portable across runtime restarts and upgrades.

Why DB too?

The database is not the agent memory. It is the operational index for accounts, pointers, subscriptions, recovery, and fast dashboard queries.