What is MinuteWork?

The short version

MinuteWork is a platform for building and operating AI-native capabilities across private Servers and explicitly published web surfaces.

For end users, MinuteWork feels like a place where agents can actually do work: follow up with vendors, process documents, coordinate workflows, publish sites, and keep context over time.

For developers, MinuteWork is the layer that lets you define the system once and let AI help implement it within strong boundaries. You define contracts, flows, schemas, and public surfaces. MinuteWork provides the runtime model, identity model, publication model, and the guardrails that keep the output enterprise-ready.

The platform model

MinuteWork has three main planes:

• Gateway is the user-facing edge and request router.
• Core owns shared coordination such as identity, routing, publication metadata, federation, billing, and receipts.
• Server runtime is the private tenant boundary where private payloads, installed capabilities, and payload-aware execution live by default.

This split matters because MinuteWork is not a central app database with AI sprinkled on top. Private payload stays with the Server runtime. Shared platform records stay in Core. Public traffic can be served from an explicit published surface without turning the public host into the owner of private data.

What developers actually build

Developers in MinuteWork work at the level of capabilities, not just pages and CRUD endpoints.

Typical authoring inputs include:

• typed schemas
• manifests for actions, queries, and routes
• public web surfaces
• flows, templates, and integration logic
• optional app-pack code where declarative contracts are not enough

The job shifts upward. You still own the system design, but you spend less time hand-writing glue code and more time defining the contracts, boundaries, and approval points that AI coding agents should follow.

What the platform and AI do for you

MinuteWork gives developers a few important things out of the box:

• a private Server model with isolated tenant runtimes
• hardened platform primitives instead of ad hoc backend invention
• Builder and local CLI workflows that understand the same contracts
• publication and hosted-release paths for public surfaces
• review, attestation, billing, and marketplace hooks for reusable packs

That means you do not start by wiring identity, multi-tenancy, deployment plumbing, or marketplace packaging by hand. You start by describing the capability and the boundaries it has to respect.

Build or integrate

MinuteWork is not biased toward building everything from scratch.

When the right external system already exists, the right move is usually to integrate it. When the platform already exposes a hardened primitive, the right move is usually to compose it. When neither is enough, Builder and the local developer workflow can generate the missing implementation surface.

The important rule is that all three paths should converge on the same typed contracts and review model.

What gets installed or published

A MinuteWork capability can land in a few different ways:

• installed into a Server as private runtime behavior
• exposed through an authenticated web surface
• intentionally published as a public web property
• later packaged, reviewed, and listed for marketplace reuse

Those are different distribution paths, but they all sit on the same core mental model: define the capability once, then activate or publish it through the right governed channel.

Start here