SLICC

The deciding trait is that it operates inside sessions you have already authenticated. That is genuinely different from every browser tool that starts from a blank profile and gets stuck at a login form, and for a task that spans an internal dashboard nobody built an API for, it is the only thing on this board that can reach it.

It is also the reason to be careful, because the same property means it can do anything you can. Pick it for automation nothing else reaches. Pick a coding agent for code.

Injection into a third-party desktop client is the failure mode and the feature at once. The target application did not design for it, does not version against it, and will change its internals without warning, so every update upstream is a chance for the overlay to break or to misfire against a different button than the one it meant. Nothing published describes a compatibility contract.

What it does right is put the shell and the browser in one workspace, so a task that crosses between them does not have to be split across two tools.

1. Conventional browser automation puts the controller outside the page, which is what makes the controller's state independent of whatever the page does. Collapsing the two means a page crash and an agent crash are now the same event, and the agent's own execution shares an environment with untrusted content.

2. The compensating argument is access: no protocol boundary means no capability gap. 3. Neither the trade nor its consequences is discussed in the published material, and no evaluation of either is offered.

Six months and thirty stars is pre-adoption, which means everything here is a hypothesis. The shape suggests a hosted product eventually, since somebody is paying for a domain and a web app, but no tier, no meter and no company structure is described, so what is being built toward cannot be read from the outside.

Moat: none yet. Likely path: it finds a wedge in browser-based automation, or the authors discover why nobody else shipped this. Position: too early to depend on, and interesting enough to watch for another two quarters.

This is not a procurement objection, it is an attribution one. Every action taken through a logged-in session is recorded as the person whose session it is, so an investigation into who deleted a channel or approved a request has no way to distinguish a human from an agent acting on their behalf. My compliance team cannot accept that ambiguity.

There is also no console, no policy distribution and no retention statement to review. Not yet, and the blocker is not a missing feature I could wait for; it is the design.

Four entry points and one of them needs nothing hosted, which is the only one I would use. A local workspace, a browser I already have, and a compiled follower for the boxes with no screen means the whole thing runs on hardware I control and the hosted app is optional rather than central. Permissive licence keeps a fork alive.

What is absent is the protocol layer, so the servers I run cannot be reached and every new capability is a change to the project itself. For something this young that is survivable, and it is still a gap.