The layer above your agents.

AI writes software faster than any team alive. It can also be confidently wrong just as fast. An agent agrees with an incomplete plan, then builds at speed. The reasoning lives in chat and scrolls away. The steps nobody watches get skipped, and every session starts from zero. So, the memory of the project becomes you. We keep reaching for a smarter model, but this isn't a model problem. It's a structure problem, and you can't fix a structure problem. And you can't fix a structure problem with a smarter model. So, Oystro wraps structure around the agent, a harness, not a tool, not a plugin, a process written down that any agent can follow. The idea is simple. The agent is fast and tireless, but it can't see its own blind spots. So, instead of asking it to check itself, the process stops and puts the work in front of you. A moment where you step in and decide. That's what a gate is. Follow the flow. In it, scaffolds the project. Define writes the plan, the spec, the tasks, the acceptance criteria, and then it stops. This is gate one. You read the plan. You fix what's wrong. You approve it. Nothing gets built until you do. Build implements it. One task, one commit. For larger projects, a fresh eyes review runs against the plan with no memory of the build, so it can't rationalize its own choices. Then verify runs the evidence. Then gate two. You see the proof and the deferred items, and you approve the release. And when the next feature comes, it loops back to define. Now, look at the middle, because this is the part people miss. Once the plan is approved, you're not in the loop for every step. Between the gates, the agent works on its own, building, verifying, recording without your intervention. You come back at the gates, approve the plan before code, approve the release after the proof. Two moments are yours. Everything in between belongs to the agent. And it leaves a trail. Months later, anyone can see what changed, why, and what proved it. Every decision linked to the work it caused and the proof it passed. The same harness handles the small stuff, too. Bugs and change requests take a lighter path without the full ceremony. The agent is interchangeable. The process isn't. Use your agent today, a different one tomorrow. The workflow doesn't change. That's Oystro, your process, every agent today.

Hope you're here after watching the Oystro concept video. Hi everyone, I'm George Koshy. Welcome to the live demo of Oystro OSS, a full life cycle software engineering protocol for AI coding agents. Let me show you. This project is empty, so let me start my agent. This is OpenCode, the agent I'll be driving. I go to the Oystro open source repo, copy the init command, and paste it in. What it does, it scans the repo and scaffolds it, the constitution, the architecture, the build log. These are real files in your repo, not in your chat. The next permitted command is Oystro define. This is where we define the project. So now it's come to the first human gate. Here you have a chance to read the plan, fix what's wrong, and approve, because nothing is built until this. Now that we've approved it, the next step is the build step, where we go one task at a time, one commit per task, no improvising over here. It's time for Oystro verify. What it will do here is run the evidence, the tests, the acceptance criteria, and the verification report. This is where you come to the second gate, where you can read the evidence and approve the release. There's a read me as well as the release notes. You'll see what the deferred items are, they're disclosed over here, and then it gets merged. You can come back after 6 months, and the entire build narrative will tell you what changed, why, and what proved it. The agent is interchangeable, but the workflow isn't. Bring any agent, keep your standards. It's free and open source, file-based with no account required. Try it on a real project and tell me where it breaks. github.com/oystro/oystro-oss. Let me do one more thing. I forgot to do this. Let's just check what's been built. This is what's been created in the first defined phase. We could kind of beautify it, for example, if I'd started the defined phase by saying, "Let me have a Shopify-style storefront with placeholder images." It would have been built to that specification. But, thank you. Try it on your project and tell me how it works for you.