# Same AI, Two Very Different Results: The Same-Name-Different-Engine PitSame AI, Two Very Different Results: The Same-Name-Different-Engine Pit > Source: > Published: 2026-10-28 19:07:48+00:00 Most multi-entry products grow separate implementations behind the same name. An open-source agent framework for HarmonyOS development (hmharness, MIT) just lived through this pit — and the user who spotted it asked one question: "It is the same AI, why is it so different?" The scene: the same Dependabot task, run from two entry points. The BrowserOS assistant panel (ACP protocol) crushed it — read mails, GHSA forensics, npm fix, tests 7/7, draft PR, all in one flow. The extension sidebar stumbled constantly. The root cause had a name: same-name, different-engine. The panel ran the full runAgentTask (complete tool registry, real system prompts with memory/skills/insights, session continuity, approval cards). The sidebar was an early hand-rolled minimal chat loop. Same product name, two different machines. The fix was not to patch the sidebar — it was to delete it and rewire it to runAgentTask: per-Origin isolated sessions (conversations continue like real threads), tool calls streamed to the activity feed, approval through a conversational confirm gate (rejections record the exact call; confirmation pre-executes next turn and injects the result). The same convergence answered an architecture question: why does the extension not use ACP? Browser extensions run in a sandbox and cannot spawn local processes — a hard browser security boundary (the official ChatGPT extension works the same way, over cloud HTTP). So in extension-land the host bridge is a loopback bridge; both channels run the same runAgentTask, differing only in transport (HTTP vs stdio) and approval UI. The product lesson: the fix for multi-entry drift is to converge on a single core and let every entry point be a different shell of the same engine. hmharness wires project creation, checks, builds, signing, install, launch, log reading, and result verification into a local toolchain so AI does not just generate code — it proves results against the local machine. Independent community project, no affiliation with Huawei or OpenAtom. GitHub: [https://github.com/swsgbl/hmharness](https://github.com/swsgbl/hmharness) · Evidence: [https://swsgbl.github.io/hmharness/evidence/aiarchitectureproductmanagementopensource](https://swsgbl.github.io/hmharness/evidence/aiarchitectureproductmanagementopensource)