Open-source AI execution management for test automation(github.com)
github.com
Open-source AI execution management for test automation
https://github.com/isagawa-qa/platform
2 comments
Hi HN, I built this to solve a problem I kept hitting: AI agents can generate test scripts fast, but without enforcement they produce inconsistent output, skip patterns, and repeat the same mistakes.
The platform uses a 5-layer test architecture (Test → Role → Task → Page Object → BrowserInterface) based on the Screenplay pattern, enforced by a governance loop that runs inside the AI agent. Every 10 actions, the agent stops, re-reads its protocol, and checks its own work. If it fails, it records a lesson and never makes that mistake again.
The kernel follows a minimalistic design. no external dependencies. I'll post about the kernel in a separate post.
Stack: Python, Playwright MCP, Claude Code.
Happy to answer questions.
The platform uses a 5-layer test architecture (Test → Role → Task → Page Object → BrowserInterface) based on the Screenplay pattern, enforced by a governance loop that runs inside the AI agent. Every 10 actions, the agent stops, re-reads its protocol, and checks its own work. If it fails, it records a lesson and never makes that mistake again.
The kernel follows a minimalistic design. no external dependencies. I'll post about the kernel in a separate post.
Stack: Python, Playwright MCP, Claude Code.
Happy to answer questions.
One thing we kept seeing is agents are very good at convincing themselves they followed the protocol even when they didn’t. Self-checking helps, but we eventually started treating the agent’s reasoning as advisory rather than authoritative.
The pattern we’ve been exploring is separating what the agent believes it did from what the system actually allows to execute. The agent can generate tests, retry, and self-correct, but any action that mutates real state still passes through an external gate enforcing deterministic constraints.
Your layered architecture probably makes that easier since the execution boundary between the agent and the browser interface is already well defined.
How well does the “never makes that mistake again” mechanism hold up in longer sessions? In our experience agents sometimes rediscover the same failure modes once enough context drift accumulates.