Same AI, Two Very Different Results: The Same-Name-Different-Engine PitSame AI, Two Very Different Results: The Same-Name-Different-Engine Pit

The open-source hmharness project (MIT) traced a multi-entry agent framework's inconsistent behavior to a "same-name, different-engine" split, where its BrowserOS assistant panel ran the full runAgentTask pipeline while its extension sidebar used an early hand-rolled chat loop. The team deleted the sidebar implementation and rewired it to the same runAgentTask core, adding per-Origin isolated sessions, streamed tool calls, and a conversational approval gate, with the extension using a loopback host bridge because browser sandboxes cannot spawn local processes. hmharness wires HarmonyOS project creation, builds, signing, install, launch, and log reading into a local toolchain so agents verify results against the local machine.

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