SOP-driven AI workflows, deployed from a repo.
PDT turns documented business processes into secure, stateful, scheduled AI workflows. Process owners define the work in Markdown. Developers attach safe scripts and tools. PDT runs the process.
Agents need more than skills.
Skills describe capabilities. Processes describe controlled work. A skill can teach an agent how to research an account, summarize a contract, or call a tool. A process defines how a specific workflow must run, when it must stop, and when a person must approve the next action.
Skills are useful.
They package reusable knowledge, instructions, scripts, and examples. They help agents perform a type of task better.
Processes are necessary.
They define the operating procedure: purpose, scope, inputs, roles, steps, decisions, approval gates, evidence, escalation, and completion criteria.
The enterprise does not need autonomous “God agents.” It needs repeatable processes that can reason inside boundaries.
Most business workflows are too judgment-heavy for classic automation and too important for loose prompting. PDT is built for the middle: structured processes that give agents room to reason while keeping execution scoped, logged, and governed.
Three clean primitives.
Reliable AI workflow software does not need a maze of brittle orchestration graphs. It needs simple files with clear responsibilities: deterministic tools for action, reasoning engines for judgment, and process documents for control.
Scripts
Deterministic Python, Node, Ruby, or shell tools that take action. Safe, auditable, and scoped to approved APIs, databases, and systems.
Agents
Reasoning engines used for fuzzy work: synthesis, classification, judgment, review, and decision support inside bounded process steps.
Markdown
SOPs as code. Plain text files that define the workflow, inject context, specify gates, and describe terminal states.
Separate the business logic from the execution.
Business logic should live in files your team can read, review, and change. The LLM processes. The PDT runner routes. Control stays in the repo.
Introducing PROCESS.md
PROCESS.md is a repo-native format for executable SOPs. It is plain Markdown so process owners can read and maintain it. It is structured enough for developers and runtimes to validate, test, deploy, and enforce.
# Process: Sales Account Research
## Purpose
Research a target account and prepare an outbound draft for review.
## Trigger
When a new account is added to the target account list.
## Inputs
- Account name
- Website
- CRM record
- Approved research sources
## Approved Tools
- search_company
- enrich_account
- draft_outbound_email
- create_review_task
## Workflow
1. Verify the account is in scope.
2. Research company context and buying signals.
3. Summarize relevant findings with evidence.
4. Draft outbound copy using the approved messaging frame.
5. Create a human review task before anything is sent.
## Approval Gates
- Outbound messages must be approved by a human.
- New claims must include supporting evidence.
## Completion Criteria
The account brief and outbound draft are ready for review, or the workflow is stopped with a documented reason.Readable by operators. Enforceable by software.
PROCESS.md is not a prompt dump. It is an operating document with runtime implications. The process owner defines how work should happen. The developer defines what the system is allowed to do. PDT makes the boundary executable.
Every process states what it is for, when to use it, and when not to use it.
The agent can only call the tools, scripts, and integrations attached to the process.
The process defines the order of work while allowing bounded reasoning inside each step.
Sensitive actions can pause the workflow until a person reviews and approves.
Outputs can require cited evidence, structured artifacts, and a durable execution record.
The workflow defines success, failure, timeout, escalation, and acceptable stop states.
PDT is the runtime for controlled AI work.
A process file is only useful if the system can run it safely. A single deployment should turn a repo into a production workflow: isolated execution, durable state, scheduled endpoints, memory, logs, retries, and human approval gates.
Define the process
Process owners write the SOP in Markdown. The file becomes the shared source of truth for the workflow.
Attach safe tools
Developers connect scripts, schemas, integrations, secrets, tests, permissions, and deployment configuration.
Deploy the workflow
PDT runs the workflow with durable state, scheduling, memory, logs, retries, and human approval gates.
Stateful execution out of the box.
Long-running AI work should not require every team to stitch together queues, workers, cron, storage, approval screens, and custom recovery logic. PDT packages those concerns into the deployment layer.
Execution state is stored outside the model context, so the workflow can pause, resume, retry, and keep a clean audit trail.
When a workflow hits a human approval gate, execution can stop cleanly and resume only after the required decision is made.
Scripts and tools run inside isolated environments with explicit permissions and clear failure boundaries.
Less brittle than visual automation. More governed than prompting.
PDT treats process knowledge as a deployable asset. Workflows live in Git, can be reviewed in pull requests, tested before release, and updated without rebuilding the whole system.
For process owners
Document the workflow in plain language. Review the exact procedure the agent will follow. Update the process as operations change.
For developers
Provide the runtime boundaries. Attach tools, validate schemas, write tests, manage deployment, and keep unsafe actions behind approval gates.
Build agents around the process, not the other way around.
PDT is being built for teams that want AI workflows to behave like operational software: scoped, testable, reviewable, deployable, and safe to run.
