MarchAi
01/12
View website
MarchAi / Bazaar

Bazaar turns judgment-heavy workflows into products.

The most important work in a company is rarely just a verifiable answer. It is deciding what matters next, opening the right surface, and carrying the workflow through to action.

Why it breaks See Autodune
VERIFIABLE WORK compile, calculate, check THE GRAY ZONE taste, review, routing, approvals, what happens next FINAL ACTION commit, fulfill, release, settle BAZAAR TURNS THAT GRAY ZONE INTO A PRODUCT Studio builds it • runtime surfaces open it • shared state keeps it coherent • one action rail finishes it
Why this work still breaks

The question starts in one place. The rest of the workflow falls apart.

The request arrives in chat or on the web. Review happens in another queue. Access is handled somewhere else. Approvals go to email. The final action disappears into an internal tool. That is why important work still depends on manual glue.

Judgment

Someone still has to decide what matters, what to show, and what should happen next.

Access

Different participants need different slices of the same workflow.

Coordination

The work needs live state, not disconnected updates across tools.

Action

The workflow still has to end in a real commitment, fulfillment, or release.

TODAY WITH BAZAAR request review approval action PRODUCT SURFACE SHARED WORKFLOW GOVERNED ACTION
Studio builds the workflow

Assistant Builder, cases, installs, and Forge turn the job into a real product.

Studio is where the workflow gets described, scoped, connected, and assembled. Bazaar does not start from a generic bot shell. It starts from the actual job, the systems it touches, the people involved, and the path to action.

Assistant Builder

Capture the job in plain language.

Cases and rail apps

Start from real workflow patterns and domain rails.

Installs and reach

Define what the workflow can see and do.

Forge

Assemble the operator-backed runtime.

DESCRIBE SELECT CASES DEFINE REACH FORGE STUDIO Builder • cases • rail apps • installs • Forge OPERATOR-BACKED PRODUCT surfaces, workflow state, permissions, final action
One workflow can open as many products

Customers, teams, partners, and field users should not need the same interface.

Different people should get different versions of the same product. Bazaar opens the right surface for each side of the workflow without duplicating the workflow itself.

Frontdoors

Simple entry for customers and public users.

Workspaces

Live surfaces for teams with state, queues, and approvals.

Bounded partner views

The exact slice a collaborator needs.

QR and channel entry

Slack, WhatsApp, or field-first flows when that is the right surface.

CUSTOMER SAME WORKFLOW PARTNER / FIELD frontdoor workspace / UI agent / channel runtime bounded surface STATE • APPROVALS • ACCESS • ACTION
Shared state keeps the product alive

Rooms, cases, contracts, approvals, grants, and offers give the workflow memory.

Bazaar is not stateless request-response. It gives the workflow a place to hold progress, permissions, terms, and coordination over time.

Rooms

Live collaboration state for the job in progress.

Cases

Workflow objects that carry status and decisions over time.

Grants and approvals

Access and decisions as part of the product.

Contracts and offers

Operational terms that stay attached to the workflow.

PEOPLE LIVE WORKFLOW TERMS teams partners consumers rooms approvals grants offers milestones contracts quotes holds commits
The product still has one path to action

Execution stays governed through one rail with permissions, budgets, jobs, receipts, and visible outcomes.

Bazaar does not leave the last step to email, another queue, or a hidden internal tool. The workflow finishes on one governed action path.

Permissions

Who can do what is explicit.

Budgets

Execution remains bounded and inspectable.

Jobs

Work is visible while it is happening.

Receipts

Outcomes remain tied to the workflow.

CHECK APPROVE RUN RECEIPT
Passports package identity and access

A passport is the bounded face of a workflow, company, object, or offering.

A passport is how Bazaar opens the workflow outward. It gives another person or organization a usable face for the system without exposing the whole stack behind it.

Public or bounded

A passport can be public, approved, partner-only, or role-specific.

Identity

It tells the outside world what this thing is and how it should be used.

Access boundary

It limits what another person can see and do.

Reusable

It can be reopened across web, channels, or generated runtime surfaces.

PASSPORT bounded face of the product what it is • who it is for • what it opens • what remains hidden public approved partner
Capsules package taste, evidence, and logic

A capsule carries the part another person or organization actually needs.

Taste does not have to stay trapped in one person's head. A capsule can package judgment, evidence, logic, or access so that another person can use the part that matters without seeing the whole system.

Taste

Portable judgment about what fits, what matters, and what should happen next.

Evidence

Proofs, readiness, or qualification slices that can be shared selectively.

Logic

Reusable reasoning and bounded workflow behavior.

Import

Another product can use the capsule without getting everything behind it.

TASTE EVIDENCE LOGIC ACCESS capsule imported into another product the recipient gets the slice they need, not the whole system behind it
Audience model

Different people should get different versions of the same product.

That is how the same workflow can serve customers, teams, partners, investors, operators, and field users without duplicating the system. Bazaar changes the surface, not the underlying workflow integrity.

One workflow

The work stays coherent underneath the surface.

Different surfaces

Each audience sees what fits its role.

Bounded sharing

Visibility and action rights stay explicit.

Lower friction

People use a product built for them instead of a generic portal.

SAME WORKFLOW shared state • approvals • action customer team partner field
Autodune helps Bazaar find the better version

It tries different product shapes, tests the full path, compares outcomes, and keeps improving the workflow after launch.

Autodune does not replace Studio, shared state, passports, capsules, or the action rail. It uses them. Its job is to shape, compare, and improve the product around the workflow.

Shape

Try different product surfaces and workflow layouts.

Test

Check the workflow from request to final action.

Compare

Score clearer, safer, or faster variants.

Improve

Keep the version people actually use better.

GENERATE TEST COMPARE PUBLISH WINNER repeat as real usage reveals a better product shape
What this launches in practice

Support, taste passports, fundraising, partner access, internal consoles, field flows, and cross-company operations all fit the same model.

Bazaar is already shaped for customer support, taste and recommendation products, partner portals, fundraising workflows, vendor qualification, field entry by QR, and domain workflows in space, robotics, and drones.

Taste and creator products

Taste passports, creator passports, gift and recommendation flows.

User-to-org workflows

Support, fundraising, hiring, concierge, claims, approvals.

Internal systems

Generated consoles, ops workflows, vendor qualification, field service.

Cross-company programs

Partner access, space operations, robotics rollout, drone mission clearance.

support taste / creator partner access internal ops space / robotics / drones
Closing

Bazaar is the product layer for what happens next.

When the work still needs judgment, coordination, approvals, bounded access, and final action, Bazaar turns it into software.

View website Back to top

Judgment

The workflow still needs someone or something to decide what matters.

Taste

Bazaar can package taste into passports and capsules that other people can actually use.

Coordination

Shared state, grants, and approvals keep the workflow coherent.

Action

The product still finishes on one governed path.