How DEX Works
DEX usage breaks down into a small number of steps. Everything past step 2 is carried by the platform and the partners assigned to the project.
1. Get access to the sandbox
A new client or partner gets access to the DEX sandbox — a working environment to see the platform and try it against a real or representative problem.
2. Define the problem and the proposed solution
This is the only step that requires a human to think hard and write clearly. In plain English:
- What problem is the customer trying to solve?
- What's the proposed approach to solving it?
This becomes the spec. The clearer the spec, the better the output — there's no separate "translation" step the customer needs to do; if you know the business well enough to describe it, DEX can take it from there.
3. DEX and the assigned partners take it from there
From the spec, DEX (with the relevant partner roles involved) produces:
- Business and functional requirements (BRD, SRS, FSD)
- A development plan and task breakdown
- Working code, built and reviewed
- QA validation
- Deployment — dev → staging → production
- Ongoing monitoring and support
Who's involved at each stage
| Stage | Primarily driven by |
|---|---|
| Sandbox access & demo | Referral Partner |
| Problem & solution definition, BRD/SRS/FSD | Collaborative Partner |
| Build, QA, deployment | Implementation Partner |
One person or company can fill more than one of these roles on the same project — see Partner Types Overview.
The consistent message
Whenever DEX is described — in documentation, on the website, in a pitch deck, in the first slide of any presentation — it should always answer the same three questions, in this order:
- What is DEX — a single agentic platform for the full SDLC.
- Why DEX — because agentic delivery is inevitable, and a partner network scales faster than direct sales alone.
- How you use DEX — sandbox access, plain-English problem definition, and the rest is delivered by the platform and its partners.