Building an AI agent orchestration platform solo at 17 yo

Hey PH! I'm Tunahan, 17.

For the past 2 months I've been building Xorviex solo — a platform that lets you define a task and have AI agents plan, code, test, and review it themselves, without hand-coding the orchestration yourself.

The hardest problem so far hasn't been the agents themselves — it's been getting a builder agent and a tester agent to actually trust each other's output without a human in the loop constantly re-checking. I ended up building a concurrent builder/tester pair with a lookahead-gated loop to solve this.

Curious how others here have approached multi-agent coordination — especially: how do you handle an agent that reports false success? That's been my biggest debugging nightmare.

Launching on PH in about 10 days — would love to hear what problems you've run into if you've built anything similar

24 views

Add a comment

Replies

Best

The false success problem is the hard one, worse than an agent just failing outright since nothing tells you to look. What's worked for me at a smaller scale is not trusting the builder's own report at all, having the tester check against something outside the builder's control, an actual test run or a schema check, rather than reading the builder's summary of what it did. If both agents are reasoning off the same transcript, a confident wrong answer from one just becomes a confident wrong answer from both. Good luck with the launch, 10 days is close.

Picking the coordination problem instead of the agent problem is the part most people get backwards for years. A concurrent builder and tester pair with lookahead gating is a real architecture, not a demo. On false success: it is not a tester quality problem, it is an information leak. A builder grading its own work grades against the same model of done that produced the work, so it cannot see the gap. And the moment your tester can read the builder's claim, it anchors on it. Two things that help. Give the tester the artifact and the original spec and nothing else. No builder reasoning, no summary, no "I have verified this works". Then define success before the build starts as something that exits zero or non zero, never as prose. If the criterion is prose, both agents will happily agree on prose. The thing to watch with a gated pair specifically is co-adaptation. Over enough runs the builder learns what your tester accepts rather than what is correct, and false success comes back wearing a different hat. That is why the criterion has to come from outside the pair. One cheap signal while you debug: log the builder's claim text. False success tends to arrive with more confident language, not less. You can measure that before you can catch it any other way.