How It Works
Zhenfy One uses a multi-agent pipeline where specialized AI agents handle each phase of the project lifecycle. Each agent is an expert in its domain.
The Pipeline
1. PM Agent (Brief)
The PM agent starts by interviewing you about your idea: who uses the app and how they get in, what it manages, how data is shared between people, what is kept and for how long, what you supply versus what the app generates, and what you will do with it first. It asks only what the idea leaves open, a few questions at a time with concrete options and a recommended default, and stops once every point is answered or safely assumed — a detailed idea gets no questions at all. You can end the interview at any point and let it draft. It then produces a structured project brief: goals, requirements, user stories, success criteria, and the decisions and assumptions from your conversation. You review and approve before proceeding. A later change to a built project is interviewed the same way, about the change: the PM reads the current spec and the decisions already made, asks only what the change leaves open, and never re-asks what is settled.
2. Tester Agent (Tests)
Writes the acceptance test plan — the test cases — based on the brief. The plan is written before any code exists; the Builder Agent later writes the executable test suite from these cases and must satisfy every one of them.
3. Security Agent (Security Plan)
Security is a default stage of every project. This agent builds a STRIDE threat model and an OWASP-mapped security test plan — including an executable suite that will attack the deployed app — and a reviewer checks the plan before the build proceeds (a rejection sends it back to the security agent; if the reviewer can't approve it after repeated attempts, the build proceeds anyway, and the security test stage against the deployed app is the real enforcing gate).
4. Ops Agent (Ops Plan)
Designs the operations plan for your project: the analytics dashboard, an uptime canary, and the alerts that fire when something looks wrong — each tailored to what your app needs — plus a runbook for ongoing operations. Hosting itself is handled by the platform.
5. Builder Agent (Build)
Writes the code based on the brief and test plan. The builder generates clean, production-ready code, and stays grounded in your brief — it uses only the content you provided and won't invent facts, names, or details you didn't ask for. Before the first build of any project it provisions an isolated per-project boundary (a namespace and a container registry — every project ships as a container) plus the datastores the app has declared, builds the app, and wires in AI features through Amazon Bedrock when the app needs them.
6. Test Runner
Executes all functional test cases against the deployed beta. If tests fail, the builder is sent the failures and repairs the code, repeating until the suite passes. A run that stops making progress, or keeps failing after repeated attempts, ends as a failed run instead of shipping a beta with failing tests, and you can retry it. A retry of a run whose tests and security tests already passed continues from that build, with the reviewer's open issues as the builder's first task; any other retry starts a fresh build from the approved brief and spec.
7. Security Tests
Runs the security suite against the deployed beta, re-attacking it for issues like leaked data, broken access control, and injection. A failure sends the code back to the builder to fix before you ever see it.
8. Ops Implementation
Confirms the monitoring the ops plan already designed — the analytics dashboard and uptime canary are created back at the Ops Plan step — and records a human-readable summary of that setup. The beta itself is built and deployed at the end of the Build step, and that is the beta the Test Runner and Security Tests stages exercise.
9. Review
A final AI review checks everything end-to-end, then the pipeline stops at the beta preview. You review the beta and either request changes (which rebuilds) or promote it.
10. Deploy to Prod
Going live is a separate, explicit action: clicking Deploy to Prod promotes the reviewed beta to production with monitoring, alerting, and analytics. Reviewing the beta does not auto-deploy.