[go: up one dir, main page]

Skip to main content

Build live tools people and agents run together

GoatDB gives browsers and agent runtimes local, reactive state that synchronizes through one coordinating server—so you can build the workflow instead of assembling its shared-state platform.

field-report-07you flagged
field-report-07agent drafting
field-report-07you confirmed
GoatDB

What becomes practical

Build the tool your work needs

Dashboards, approvals, rosters, and field apps—many tools over one shared state GoatDB, live for people and agents alike.

Live dashboards

Admin panels, dispatch boards, and metrics that re-render the moment data changes—queries push to the screen; sync pulls in everyone's edits.

Approval queues

Requests with statuses, owners, and an attributable record of who approved what—teammate or agent.

Shift boards

One live roster the whole crew checks from their phones; swaps route through a manager's approval and reach every device moments later.

Field apps that work offline

Inspections, job capture, and sign-offs with zero signal; the phone holds the truth and syncs when coverage returns.

Offline-first utilities

Checklists, budgets, and trackers that open instantly, keep working offline, and sync when connected.

Agent teams

Several agents divide the work, each with its own permissions, every action attributable; people steer and approve from any device.

Architecture compression

Years of platform work, collapsed into the application

Realtime collaboration usually means stitching together storage, APIs, offline replay, synchronization, merge, provenance, recovery, and operations. GoatDB integrates that shared-state burden into a single deployable application/server binary.

The conventional platform project

Specialized systems to build, connect, and operate

  • DatabasePersistence and indexes
  • API layerAccess and transport
  • Realtime syncFan-out and replay
  • Offline stateLocal reads and writes
  • Merge logicConcurrent changes
  • Audit historyAttributable mutations
  • RecoveryHistory and restoration
  • OperationsDeploy and maintain

The GoatDB path

GoatDBGoatDB

One deployable shared-state system

Local repositories, reactive queries, authorization, sync, merge, signed history, persistence, and bounded replica-assisted recovery.

The application, server, and browser client are bundled and served together for simple deployments, rollbacks, and updates.

You still own the application

  • ExperienceUI, domain model, and product behavior
  • IdentityMap real actors to application sessions
  • AgentsOrchestration, tools, retries, and guardrails
  • PolicyApproval semantics and human checkpoints

GoatDB owns the shared-state mechanics

  • Local statePersistence and reactive in-process queries
  • SynchronizationAuthorized server-coordinated repository sync
  • HistoryStructural merge and signed secure-mode commits
  • Shared-state serverAccess checks, persistence, and repository isolation
Read the architecture and isolation details

Measured speed

One loader. Then nothing ever loads

Apps where nothing ever spins are usually out of reach—they take an architecture most teams can't afford to build. GoatDB makes it the default: each repository loads once, the way a desktop app opens a document, and from then on every read, write, and screen update runs at memory speed—the same in the browser as on the server. No per-interaction spinners, no optimistic-state machinery, no cache tier to maintain.

Made for shared work

  • Focused repositoriesOrganize each workflow into a fast, predictable local working set.
  • Continuous collaborationPeople and agents revisit and update the same live state.
  • Local-first workKeep working locally while synchronization catches up.
  • Verifiable historySecure-mode changes are tied to cryptographic signing sessions.

Built for instant, live apps

  • Every opened repository is a memory-resident local replica, making reads instant and independent of network latency. Bounded repositories keep that performance predictable.
  • A predicate scans the working set when first opened, then stays live as data changes—ideal for interactive views, monitoring, collaborative apps, and agents.
  • Remote updates currently converge in around 700–1000ms. Faster synchronization is actively in development.
  • Every secure commit is cryptographically signed, giving collaborative apps and agents verifiable writes by default.

One focused data layer for building small, reactive, collaborative apps quickly—without assembling a database stack.

Open source · MIT licensed

Start with shared state, then shape the app around your work

Initialize a project, connect the people and agents your workflow needs, and keep the whole shared-state plane in code you can inspect.