Agentic browser work is getting good enough that teams are starting to trust it for real workflows: researching, filling forms, testing dashboards, and operating internal tools.\n\nBut once an agent can browse and click, the hard question changes from can it do the task to can we prove what happened?\n\nAt Armorer Labs, we keep coming back to a simple pattern: separate the agent planning loop from the control plane that owns tool permissions, policy, human approvals, and run receipts.\n\nThat separation matters most around side effects. A browser agent should be able to propose a click, a post, or a submit action, but the runtime should record the requested action, the page context, the approval scope, and the final verification evidence. Screenshots are helpful, but they are not enough by themselves. Teams need a structured trail that says what was attempted, what was approved, what was actually clicked, and what URL or artifact proves completion.\n\nFor Armorer and Armorer Guard, the goal is to make that operational layer local-first: agents can run on your machine or server, while the guard/control plane keeps the audit trail and enforces policy before external side effects happen.\n\nThe interesting design question is where this boundary should live. MCP gateway? Browser tool wrapper? Agent runtime? A separate local control plane?\n\nMy current bias: put the enforcement as close to the tool call as possible, then store receipts somewhere durable enough that a human can inspect them later.\n\nCurious how others are handling this for production browser agents. Are you logging raw traces, structured receipts, human approvals, or all three?
Agent = Model x Harness: Your Eval Layer Is Part of the Agent, Not a Tool Beside It