We will be undergoing planned maintenance on Oct 7th 6:00AM UTC / Oct 7th 2:00AM ET

The Harness — Web-First Multiplayer Agents on Your Cloud

A shared agent workspace for every team: plan, run, and review work in the browser, then self-host it on the cloud you trust.

Comment

Inspiration

The Harness makes AI agents multiplayer.

Most agent products still hide useful work inside one developer's terminal or one private chat. Real work is collaborative: someone frames the problem, teammates clarify the outcome, tasks are delegated, specialists act, reviewers challenge the result, and a human decides what ships.

We built The Harness so that entire loop can happen in one shared, web-first workspace. Every teammate can participate from a browser, and every organization can host the same Harness on the cloud it already trusts.

What it does

The Harness turns team conversations into visible, governed agent workflows:

  1. A teammate creates a project and describes the outcome.
  2. The team discusses scope using task threads, comments, replies, mentions, and agent labels.
  3. A scoped agent is launched from that shared context.
  4. Orchestrator, Builder, and Reviewer roles split the work into isolated, reviewable drafts.
  5. Progress, evidence, and delivery state return to the project—not to a disappearing terminal session.
  6. A human asks for changes, approves the result, or hands execution to another runtime.

The browser workspace combines project management, shared chat threads, files, code, live preview, and agent activity. Non-developers can shape the work and inspect what happened; developers retain explicit execution, storage, and merge boundaries.

This is a Taskmaster project because the agent does more than answer a prompt. It carries a messy team objective through a multi-step workflow and returns evidence that people can review.

Web-first. Multiplayer. Hosted on your cloud.

The web application remains useful without a desktop shell, local daemon, browser extension, or special machine. Optional local capabilities fail closed and never block workspace startup.

Organizations can self-host the same product on their preferred infrastructure. The first-class deployment profiles are:

  • Google Cloud: Cloud Run or Firebase Functions Gen 2 for compute; Firestore or Cloud SQL for PostgreSQL as the authoritative project store; Google Cloud Storage or Firebase Storage for private objects.
  • Cloudflare: Workers for compute; D1 for relational project and document data; R2 for private objects.

The browser-facing contracts do not change when the provider changes. Provider credentials and database or bucket identifiers never enter browser code. Provider and tenancy choices are pinned when storage is allocated, so changing a default cannot silently migrate data or fall back to another cloud.

The architecture is intentionally extensible to additional providers: cloud differences live behind typed compute, document, relational, and object-storage adapters rather than inside the product experience.

Built with Google

The production AI transport uses the official Google GenAI SDK for Gemini 3.5 Flash streaming, tool calls, stop reasons, and usage accounting.

An authenticated Gemini Live API route can turn an approved assistant response into a spoken 24 kHz audio reply. The API key remains server-side; the browser receives only the generated audio.

For the Google deployment profile:

  • Cloud Run hosts the private project-management service.
  • Firestore implements the same scoped Kaneo project-store contract used by D1 and PostgreSQL.
  • Firebase Functions Gen 2 wraps the same signed HTTP handler as Cloud Run.
  • Cloud SQL for PostgreSQL is supported through the relational adapter and generated row-level-security policy.
  • Firebase Storage uses the Google Cloud Storage object boundary with short-lived, exact-object signed requests.

The central web gateway authenticates the user and organization, signs a short-lived handoff, and sends only the typed application context required by the private project service.

One schema, multiple safe storage backends

The Drizzle schema is the single source of truth. It generates:

  • Firestore collection manifests
  • Firestore composite indexes
  • deny-by-default Firestore client rules
  • PostgreSQL row-level-security policies
  • checked D1 and PostgreSQL migrations

Only one selected backend is authoritative; The Harness never dual-writes databases for correctness.

Firestore paths are scoped beneath the active organization. PostgreSQL enables and forces RLS with a transaction-local organization identifier. D1 uses the same domain repository and tenant predicates.

Plugins and gatekeepers receive a narrow Firebase-style facade—document get, upsert, delete, and prefix-list plus private object operations. They never receive raw SQL, cloud credentials, arbitrary provider URLs, or unrestricted bucket access.

How we built it

The Harness is a TypeScript monorepo centered on a TanStack Start web application. Project management is a private typed Cap'n Web target with a provider-neutral Kaneo project store.

The selected project store owns projects, tasks, columns, comments, agent threads, delivery state, idempotency, replay claims, and concurrency. Realtime is deliberately thin: the browser polls a compact activity revision and fetches the full feed only when it changes.

Agent execution is separated from project recording. A project mutation can create a pending delivery, but the authoritative store must claim and update that delivery before work proceeds. This keeps browser retries, runtime restarts, and cloud handoffs from duplicating work.

Human control is explicit: drafts remain isolated, permission expansion requires approval, storage lifecycle belongs to the organization, and merges are deliberate.

Challenges we ran into

The hardest challenge was finding one honest domain contract across D1, PostgreSQL, and Firestore. Their query and transaction models differ substantially. We solved this by modeling project behavior instead of exposing database APIs, then making the selected store the sole authority.

The second challenge was providing Firebase-like ergonomics to plugins without giving them Firebase-like ambient power. Reviewed manifests, fixed operations, tenant-scoped paths, pinned allocations, and exact-object upload signatures let plugins store useful data without receiving infrastructure credentials.

The third challenge was making agent work understandable to teammates who did not configure the agent. Shared context, visible delegation, durable delivery state, and explicit review became product features rather than implementation details.

Accomplishments we're proud of

  • A genuinely browser-first path from discussion to scoped agent work and review
  • Multiplayer project threads that keep people and agents in the same context
  • One typed project contract across D1, Firestore, and Cloud SQL/PostgreSQL
  • One signed compute handoff across Workers, Cloud Run, and Firebase Functions
  • Drizzle-generated Firestore rules/indexes and PostgreSQL RLS
  • Firebase-style gatekeeper storage across Firestore, GCS/Firebase Storage, D1, and R2
  • Gemini streaming and Gemini Live audio through Google's official GenAI package
  • Architecture, transaction, storage-signing, handoff, and end-to-end tests
  • A self-hosting model where organizations retain their identity, policy, and data boundaries

What we learned

Agentic software becomes more useful when people who did not configure the model can still understand its state and move the work forward. The shared surface matters as much as model quality.

Cloud portability also has to be a domain decision, not a marketing promise. A compatibility layer that copies data creates competing sources of truth. A typed store, pinned deployment profile, and generated security artifacts let organizations choose their cloud while keeping one product and one authority.

What's next

Next we will expand reusable agent-team templates, richer delivery evidence, organization-level deployment automation, and OpenTelemetry-compatible traces in the project timeline.

The long-term goal is simple: every organization gets its own Harness on the cloud it trusts, and every teammate gets a safe browser-first way to turn shared intent into agent-assisted delivery.

Built With

Share this project:

Updates

Submission history