
UpTrajectory Review
The article makes a case that most businesses building AI agents are asking the wrong first question. They obsess over how agents perceive web pages—screenshots versus DOM versus accessibility trees—and then how those agents take action. The author, who previously championed the accessibility tree as the optimal interface, now argues that the location of the agent matters more than its sensory apparatus. He identifies three architectures: agents embedded directly on your website, browser extensions that co-browse with users, and fully external cloud agents that operate independently. The industry's energy and venture funding currently flow toward the latter two, which promise maximum reach with minimal integration burden. The author believes this is backwards for most enterprises, especially those in regulated industries or with brand reputations to protect.
For a small-business operator, this framing is immediately practical. You have likely already fielded calls from vendors selling AI chatbots, 'AI employees,' or automation platforms that promise to interact with your systems from the outside. The article asks you to flip the script: what if the agent that represents your business to customers lives on infrastructure you control, with logging, guardrails, and kill switches you can actually reach? This matters because when an external agent misquotes your pricing, books an impossible appointment, or hallucinates a refund policy, the customer blames you—not the third-party tool. Your support queue fills with problems you cannot diagnose because the failure happened inside someone else's black box. On-site placement means you own the failure modes too, which is precisely the point.
What is genuinely new here is the explicit linkage of agent architecture to accountability, not merely security or performance. The AI discourse has been dominated by capability—what can these systems do?—with governance treated as a downstream concern. The author treats governance as the upstream design constraint that should shape everything else. Where we are skeptical: the article elides the genuine cost and technical complexity of building capable on-site agents. Small businesses rarely employ the engineers who can implement accessibility-tree interfaces, tool-exposure layers, and robust sandboxing. The 'build on your own site first' advice risks becoming 'build what you cannot afford, then scale later.' The author acknowledges reach as a problem to solve subsequently, but for a resource-constrained operator, 'later' often means 'never' if the initial investment does not show immediate return.
The second-order effects deserve attention. If this architectural preference gains traction, it advantages established platforms with existing developer ecosystems—think Shopify, Square, Salesforce—who can offer on-site agent hosting as a native capability. Smaller SaaS vendors and custom-built sites get squeezed between the complexity of DIY implementation and dependency on platforms that may not serve their niche. Conversely, browser-extension and cloud-agent vendors will not disappear; they will likely pivot to selling governance dashboards and compliance wrappers, claiming to solve the very liability the article identifies. The article also quietly presumes that businesses have APIs worth exposing as tools, which assumes a level of backend modernization many small operators have deferred.
What to watch: whether major platforms begin certifying or insuring on-site agents as a competitive differentiator, and whether regulators start asking specifically about agent provenance in consumer protection or data privacy enforcement. What to do now: audit any AI tool currently interacting with your systems or representing your brand externally. Document where it lives, what it can access, and who holds the logs when it errs. If you are evaluating AI vendors, add 'agent location' to your checklist alongside accuracy and price. The article's core insight—that reach without governance is liability, not asset—applies whether you build or buy. Start by knowing where your agents sleep at night.
The accessibility-tree argument from the author's previous piece remains relevant background: if you do build on-site, designing for machine readability through established accessibility standards gives you cleaner, more maintainable agent interfaces than scraping-dependent alternatives. This is not merely an accommodation play; it is architectural hygiene that pays dividends across human and machine users alike. The two articles together suggest a coherent philosophy: the businesses that thrive with AI will be those that treat machine customers as seriously as human ones, with interfaces designed explicitly for both, and with accountability structures that keep the business in the loop rather than at the mercy of external automation.
“Reach without governance is a liability” — InfoWorld
Takeaway: Audit where your AI agents live—on-site, in-browser, or off-browser—because location determines who owns the failure and who can fix it.
Excerpt from the original — InfoWorld
When I talk to people about agents interacting with websites, the conversation almost always starts with perception: how does an agent “see” a page? Is it screenshots or the DOM or the accessibility tree? In my previous InfoWorld article, “Accessibility is the first-class interface for AI agents”, I argued that the accessibility tree is becoming an increasingly important interface between websites and AI agents. From there the conversation shifts to actuation, and to ways of making it less brittle, which let a site expose its own actions as callable tools instead of forcing an agent to guess at buttons and forms.
That conversation matters. But it leaves out a more consequential architectural question, one that determines who is accountable when an agent gets something wrong: where does the agent live?
There are three plausible homes for an agent that interacts with your business …