>PromptOne_

Documentation

Overview

PromptOne turns a description of the work into a workflow your team operates, on Swiss infrastructure, under Swiss law.

What PromptOne is

You describe a process in plain language. The builder turns it into a workflow: agents that do the reading and the judgement, steps that call your systems, and a gate wherever a person needs to decide. Your team then operates that workflow. They watch it run, inspect any step, and approve what needs approving.

The product is the builder, but the story is the operator. Everything below exists so that the people running the work can see exactly what happened and why, and so that nothing reaches your data without an authorization somebody granted.

The loop

  1. Describe the work to the builder, in your own words.
  2. The builder creates the agents, imports the knowledge they need, draws the steps, and flags the connections that need your authorization.
  3. You publish. The definition is frozen at that moment and given a version.
  4. It runs, on a schedule, on a webhook, on an API call, or when somebody starts it.
  5. People approve at the gates, and every step is recorded as it happens.

What that looks like

Take client onboarding. The description is one paragraph, written the way you would explain it to a colleague:

Onboard new corporate clients: read the KYC pack, screen it against our compliance rules, get sign-off on anything high risk, then file the dossier and notify the team.

From that, the builder produces a workflow whose every step is on the canvas and can be opened on its own:

  1. Read the KYC pack that arrived.
  2. Extract the client profile from it.
  3. Screen that profile for sanctions and politically exposed persons, against the knowledge you attached.
  4. Stop at a person for sign-off on anything high risk.
  5. File the dossier to your document store.
  6. Notify the team in your channel.
  7. Send the confirmation by mail.

None of that was configured by hand. What you decide is where the gate sits and which connections the last three steps may use, and both are authorizations a person grants rather than settings the builder picks.

Three seats

SeatWhat it does
The builderAuthors and changes workflows. It is the only thing that does.
The operatorRuns, inspects, annotates and approves. Cannot edit a workflow's graph.
The administratorGoverns departments, connections, knowledge, members and spend.

One rule shapes the whole platform: only the builder changes a workflow. A person who wants something different describes the change, and the builder makes it. That is what keeps every change attached to a reason.

Where to go next

  • Organizations, departments and roles, for how access is scoped.
  • The builder, for what it can author and what it can see.
  • Connections, for how a workflow is allowed to reach an outside system.
  • Sovereignty and data residency, for where your data sits and why foreign law does not reach it.