Point an Agent at Your App. Get a Redesigned One Back.
It started as a chore. We wanted a new laptop to join an Aitherium workspace the way a real customer would: download the tools, install them, log in, connect — without us hand-holding every step. One command, hands off.
The headless half was easy. A single installer that takes a token, writes the config, and you're live with cloud inference and the full MCP tool set. Done.
Then came the interesting half: what if an agent did the whole thing on your behalf? Not "the agent prints instructions for you to follow" — the agent itself goes to the website, runs the auth flow, and approves it. The way you would.
That ambition cracked open a problem that turns out to matter far more than laptop onboarding.
The deceptively simple goal
The login is a device flow — the same pattern the GitHub CLI uses. The CLI shows a code, you open a page in your browser, you're already signed in, you click Authorize Device, done.
For an agent to do this autonomously, it needs to be the browser that clicks Authorize — logged in as you. We have a centralized headless browser service for exactly this: open a session, observe the page, click, type, snapshot. The agent drives it.
So we minted a session token for the owner, dropped it into the browser as the auth cookie, navigated to the approve page, and watched it...
redirect straight to /login.
The bug that taught us something
Here's the trap, and it's a good one.
Our session token was valid. We proved it: the identity service happily accepted it as a Bearer token and returned the full user. The browser service was injecting the cookie correctly and delivering it to the origin. Every individual piece worked.
But the page kept bouncing to login.
The reason is a detail every modern web app shares and almost nobody thinks about: the page decides whether you're logged in on the client, in JavaScript, before it ever asks the server. Our SPA's auth context reads localStorage — an auth_token and a serialized user object — and only then validates against the API. A real login writes both. We had injected a single httpOnly cookie. The cookie was real, the token was real, but the page looked in localStorage, found nothing, and redirected before the cookie ever mattered.
A synthesized "just the cookie" session is not a session. A session is the complete client state a real login leaves behind — cookies and localStorage, bound to the right origin, with proper expiry. (We also learned the browser silently drops cookies that lack an expires field. Hours of "it should work" live there.)
Once we built the full session state — the cookie, the tenant/user cookies, and the exact localStorage keys the app restores from — the agent's browser was indistinguishable from a human who'd just signed in.
Two ways to be you
With that understood, "log in as the owner" split cleanly into two honest paths:
For our own apps, we own the identity service — so the platform can simply mint your session itself. There's no reason to make you paste a cookie. A trusted internal call (gated by the inter-service secret, scoped to owner/admin accounts) issues a real owner session, and the agent injects it. Zero manual steps, and it survives restarts because the token is persisted exactly like any other login.
For third-party apps we don't control, you can't mint anything — so you capture the session you already have. The browser companion extension exports the full storage state (cookies + localStorage) of a site you're logged into, and the agent reuses it. Same injection, real session, no credential handling, no fighting someone else's MFA.
Either way, the agent ends up driving a browser that is genuinely, completely authenticated as you.
The proof: an agent redesigned one of our own apps
The laptop onboarding was the appetizer. The real question was whether this generalizes into something we've wanted for a long time: point an agent at a web app — especially one of your own — and have it extract everything and ship a redesigned version.
So we pointed it at one of our internal portal-kit apps. The whole loop ran autonomously:
- Authenticate. The platform minted the owner session, built the full storage state, and the headless browser opened the app — landing authenticated, not at a login screen.
- Extract. In-session, the agent called the app's own data APIs. They returned
200. Real records came back — staff, projects, people — the actual content behind the login wall, not a public landing page. - Redesign. That content fed the creative pipeline, which produced a rebranded page.
- Deploy. The redesigned page went live at a real URL, served and reachable.
Browse → extract → redesign → deploy. End to end. No human in the loop.
The first time the run printed redesigned page LIVE with a working link, it stopped being a demo and started being a capability.
Why this is the interesting part
The laptop onboarding is genuinely useful — an agent can stand up a new machine for you, hands off. But the thing underneath it is bigger.
Most "AI browses the web" demos scrape public pages. The hard, valuable version is operating the authenticated app — the dashboard, the CRM, the workspace that lives behind a login. That requires the agent to hold a real session and behave like a signed-in user. Get that right and a long list of things become routine: migrate me off this SaaS, audit this internal tool, regenerate this app's UI, do this multi-step task in that portal while I'm asleep.
The same primitive — a browser that is authentically you — is the foundation for adaptive computer-use across the board. Onboarding a laptop and redesigning an app are just two early uses of it.
What's next
The redesign today ships a polished page. The next milestone is deploying a full interactive app — wiring the generated UI to the source app's real APIs through our code-generation pipeline, so "redesign" means a working application, not a landing page. The handoff that pipeline consumes is already produced; closing that last gap turns "here's a prettier version" into "here's the rebuilt product."
But the lesson we'll keep is smaller and more durable than any of that: an agent acting as you is only as real as the session it carries. Make that session complete, mint it or capture it honestly, and the agent stops simulating you and starts being you — in the browser, where the real work lives.
We pointed an agent at our own app and got a redesigned one back. The interesting part is everything that becomes possible once an agent can truly log in.