I started Obsidian Insights with one mission: bring enterprise-grade operating discipline — the kind I spent eighteen years building for large organizations — to businesses that can't hire a platform team.
This week that mission collided with three signals from the product announcements, security research, and practitioner feeds I follow. Each one is AI gaining a new kind of reach.
The first is reach into your systems: persistent visual workers — agents that operate software the way a person does, by looking at the screen, and keep operating it after the demo ends.
The second is reach into the physical world: sensing research in which specialized radio hardware captures how wireless signals reflect through a room, and a model interprets those reflections — enough to infer that a space is occupied, or that someone in it is moving, without a camera. To be precise: this is purpose-built hardware plus a model, not a general-purpose AI that sees through walls, and it is not a capability you drop into an existing product. The safety applications are obvious. So is the privacy question it raises about how much a system can infer about people from signals nobody thought of as data.
The third is reach into evidence: models that can read months of logs, configurations, code, and change records at a scale no person will sit through, and surface the drift, the inconsistencies, and the buried errors. That capability is available to you. It is also available to whoever probes your systems first.
Three stories that are actually one: AI's emerging power is expanded access to reality — and every new form of reach raises the cost of an unsupervised mistake. Each one needs its own boundary, its own evidence standard, and a human at the consequence gate.
The opportunity is real. So is the architecture it demands. Here is how I am thinking about both.
In Brief
The Story: The Agent That Doesn't Log Off
The most interesting shift in this wave of AI is not smarter answers. It is persistence.
Products now exist whose whole premise is that the agent stays on: watching a queue, operating business software through its visual interface, carrying tasks across hours instead of turns. Warmwind, to take one current example, describes each of its AI workers as running on a dedicated cloud computer, interacting with software using a virtual mouse and keyboard. Think of a visual worker as a digital operator using the same screens, mouse, and keyboard as an employee — rather than a software integration talking to an API. It is automation at the screen level, where the brittle scripts of the RPA era used to live.
For a small or mid-sized business, that premise deserves attention for one specific reason: your most important software is probably your oldest. The scheduling system, the quoting tool, the industry-specific package you bought a decade ago — the systems that run the day rarely have the clean APIs that modern AI integrations assume. A worker that reads the screen doesn't need the API. That is a genuinely new door into software that was never built to be automated.
The question is what you do once the door is open.
My Architect's Read: It's a Bridge, Not a Destination
Here is where I want to push past the demos, because this is the decision a business owner actually faces.
A screen-level agent that frees data from a legacy system is a bridge. It gets value flowing now, without waiting on a replatforming project. But I would not build a business on the bridge itself — visual automation carries an ongoing per-worker cost, and it inherits every quirk of the interface it watches.
The pattern I recommend runs the bridge and the fix in parallel:
| Path | Time to value | Running cost | Risk profile | Exit |
|---|---|---|---|---|
| Fix the legacy layer | Slow | Low once built | Depends on vendor cooperation | You own the result |
| Rent a visual-worker bridge | Fast | Recurring, per worker | Breaks when the screen changes; data flows through a third party | Easy to stop — if you planned for it |
| Rebuild the platform | Slowest | High during build | Classic replatforming risk | You own the result |
The bridge earns its cost while one of the other two rows is underway — and it gives you something replatforming projects almost never have: a live comparison. While the new platform comes up, you can run both paths against the same work and compare outputs before you cut over. When the bridge and the destination agree for a sustained stretch, you have real evidence, not a migration leap of faith.
When the bridge can stay
I should be fair to the bridge. For a narrow, stable, low-consequence workflow — pulling a nightly report out of a system that will never get an API, re-keying orders between two tools that both work fine — a visual worker can be a permanent operating choice, as long as the economics, the reliability, and the ability to reverse a mistake all stay favorable. Where it gets risky is as the permanent control plane for the things the business runs on: core records, pricing, customer commitments, high-consequence approvals.
So the rule I use: run the bridge to create value now, while building the smallest owned capability that removes the highest-value dependency. That may be an API, an export pipeline, a database sync, or a targeted enhancement to the platform you already have. It is not necessarily a rebuild.
BEFORE THE FIRST INVOICE — FOUR LINES
- Scope — the workflow the bridge is allowed to handle, and nothing adjacent to it.
- Ownership — the data and business logic that stay yours, in a form you can read without the vendor.
- Cutover threshold — the reliability and output-comparison bar the owned path must clear before it takes over.
- Exit — the fallback if the bridge breaks, gets expensive, or the vendor disappears.
Where Should an Agent Live?
The emerging industry default says every persistent agent gets its own dedicated virtual machine. Full isolation, rented by the hour.
I understand the appeal, and for some risk profiles it is right. But I would not accept it as a default, for two reasons.
First, isolation layers fail. Agents finding their way out of constrained environments is a documented failure mode — it is precisely why the vendors building those sandboxes keep hardening them. A rented wall is still a wall you have to verify.
Second, the economics compound. A dedicated cloud machine per agent, per task, around the clock, is a meaningful line item for a small business. In my own operation, the math pushed me the other way: I bought my own hardware, because owned capacity that runs every day beats rented capacity you pay for by the hour.
The mistake underneath the default is treating isolation as one thing. It is four things, and they answer four different questions:
| Layer | The question it answers | The mechanism |
|---|---|---|
| Change control | Where do changes land? | Branches and a review gate — nothing merges itself |
| Access | What can it reach? | Least-privilege credentials — its own scoped identity, never yours |
| Runtime isolation | What can it do while it runs? | A container, a restricted worker account, or a dedicated VM when the consequence justifies it |
| Recovery | How do we get back? | Snapshots and backups — a safety net, not a control |
Here is the pattern I am testing in my own operation — and I want to be straight that it is architecture-in-progress, not a finished recommendation.
Change control is my economical default for code work. Each agent task runs in its own version-controlled branch — its own copy of the work, cheap to create, cheap to destroy. Completed work waits at a review gate, and a person approves it into production: the same discipline software teams have trusted for years, applied to every kind of agent output.
I want to be precise about what a branch does not do. A branch does not contain network access, browser sessions, production credentials, customer data, or an unsafe command on the host. It controls where changes land. The other three layers have to be chosen on purpose, and the right choice depends on the work. A drafting agent with read-only access needs a branch and a scoped credential. An agent that can send, purchase, or change a system of record earns the container — and sometimes, after all, the rented machine. Match the level of isolation to the consequence of the work.
Recovery deserves the same layering. A single nightly snapshot is not a plan; it is one restore point that the same incident can take with it. What I run instead: short-term local snapshots for fast rollback, longer-lived offsite version history, at least one protected known-good restore point that no automated process is allowed to thin, and a restore test on a schedule — because a backup you have never restored is a hope, not a control. The objective is not that every snapshot lives forever. It is that no single incident can erase every usable way back.
Log immutably. Every action, every input, every cost, appended to a record nothing can quietly edit.
Five Controls I Want Around Every Agent
The agent gets its own scoped credential — never the full permissions of the person who created it. Drafting replies does not justify sending, deleting, or rewriting mailbox rules.
In my own agent instructions I authorize a small cap — often three dollars — for a bounded task. Below it, the agent works without interrupting me. At it, everything stops and I get a message asking to proceed. One design choice removes approval friction and caps the blast radius of a loop or a bad assumption.
A new port listening, an endpoint that lost authentication, a scheduled scan that quietly stopped, a dependency with a fresh vulnerability. Keep the checks deterministic — and give the watcher a dead-man switch, because a monitor that fails silently buys confidence without buying protection.
Reading, comparing, and drafting are preparation — let them move fast. Sending, purchasing, and changing a system of record are commitments — they pause at a decision point. The distinction should be visible in the architecture, not implied in a policy document.
Enough record to answer five questions: What did it use? What did it attempt? What did it cost? What changed? How do I reverse it?
The Watchtower, Not the Root Operator
Strong local models — models that run on hardware you own — are becoming genuinely useful security analysts. They can correlate findings, explain what changed overnight, rank likely risk, and draft the remediation plan, all without sending your system's evidence to an outside provider, and without consuming a frontier-model subscription for every routine check.
This is the third kind of reach — reach into evidence — put to work on your side of the wall. The model's real advantage is not cleverness. It is stamina: it will read every line of six months of logs and configuration history and notice the port that opened in March and never closed.
I am investing in exactly this. But there is a line I will not move: the model recommends; it does not patch unsupervised.
A capable model with administrative access can still confidently repair the wrong layer, break a working service, or act on a hallucinated finding. The architecture that captures the value without the regret splits the roles:
- Deterministic tools collect evidence and enforce known rules.
- The local model interprets, prioritizes, and proposes.
- A human approves consequential changes — with a verified rollback path.
- Automated checks confirm the fix closed the finding without breaking the service.
A watchtower on the wall, not a root operator inside it.
The Production Line Keeps Moving
The paradigm I find most promising in all of this reverses the usual fear about human oversight — that people become the bottleneck.
Run it like a night-shift production line. The agents keep producing: drafts, analyses, fixes, candidates — continuously, without waiting. The human does not pace the line; the human stands at the quality gate, judging finished work and releasing what deserves to ship.
That design does more than protect throughput. It keeps a person's values in the loop precisely where they matter — at the moment of consequence. The machine brings the speed. The human brings the heart. Businesses that get this balance right will out-ship the cautious and out-trust the reckless.
The 30-Minute Move
THE BOUNDARY CARD — FIVE LINES
- Access — the minimum information and permissions it needs. Nothing inherited. If it can observe people — a mailbox, a calendar, a camera, a room — say what it may infer, retain, and disclose.
- Actions — what it may complete without asking.
- Spend — the hard ceiling per run, day, or month.
- Stop — the conditions that pause everything and alert a person.
- Evidence — the record that proves what happened and how to reverse it.
Then — this is the part most people skip — break something on purpose. Revoke a permission. Stall a service. Trip the spending cap. You are not testing whether the agent succeeds. You are testing whether it fails in a way you can see, understand, and stop.
What I Am Watching
The next wave will not be defined by smarter answers. It will be defined by systems that stay present — monitoring, preparing, and acting over time. That makes security a continuous operating function, not a pre-launch checklist.
And as AI gains reach — into your systems, into the rooms your business operates in, into the evidence of what it did — every new form of reach needs a matching boundary, an evidence standard, and a human at the consequence gate. That is what makes architecture — bridges with exits, isolation matched to consequence, logs with integrity, gates with humans at them — the real differentiator.
The businesses that win this wave will not be the ones that grant agents the most freedom first. They will be the ones that make trust inspectable.
Reader Question
Reply and tell me. The answer is usually the first line of your boundary card.
Sources and Notes
- Anchored in William McBride's editorial reflections recorded September 1, 2026 on emerging agent, sensing, and security signals from public product announcements, security research, and practitioner feeds.
- Warmwind's description of dedicated cloud workers operating software visually: company launch materials, August 2026. Referenced as a current example of the pattern, not an endorsement or evaluation.
- Wireless-reflection sensing referenced from public research discussion. In that work, specialized radio hardware captures signal reflections and a trained model interprets them; it is treated here as an emerging, hardware-dependent capability — not a general-purpose model feature and not a product category.
- Sandbox-escape and agent-containment failures referenced as an industry-documented risk class; no specific vendor incident is asserted.
- Security techniques discussed here should be tested in isolated environments before use on consequential systems. Nothing in this issue is an endorsement of a specific product.
Obsidian Insights by William McBride
A practical field note on AI, operations, and trustworthy execution.
INTELLIGENCE CRAFTED BEAUTIFULLY.