Launched this week
Lyto
"One AI agent across your browser, tools, and messages "
272 followers
"One AI agent across your browser, tools, and messages "
272 followers
Lyto AI is a Chrome extension that gives you full control over your browser. Open and close tabs, scroll, click, fill forms, and interact with every DOM element. Integrates with Google Docs, Gmail, and Google Sheets. Research, automate tasks, and organize your workflow — all inside Chrome.
Free Options
Launch Team / Built With
Lyto
Appreciate the straight answer. The part I'd watch closely is the Gmail/Sheets step — since page content is processed server-side, will the whole inbox/sheet DOM get shipped, or can you scope it to just the rows/region the action actually touches so the server only sees what the task needs? Even an opt-in 'this site stays fully local' allowlist would make me comfortable pointing it at a work account.
@arystan_tanekov The cross-app coordination piece is tough — how'd you decide which integrations to ship first? Did you let user requests drive it or had a specific sequencing strategy?
The persistent workflow memory across tabs and tools is the part that stands out - that context loss is exactly what breaks when you bounce between ChatGPT and your actual tabs. Where does that memory actually live: locally in the extension, or synced to your backend (matters a lot once it is reading Gmail and Sheets)? And when it acts on a page, is the DOM automation running locally in my browser while only the reasoning is hosted, or does the page content get shipped server-side on each step?
Lyto
@noctis06 Great questions, happy to be transparent on this.
Memory lives locally in the extension storage on your account, it never leaves your device.
For DOM automation, page content does get processed through our server so the reasoning can act on it. We know that raises valid questions especially as we add Gmail and Sheets, and handling that responsibly is something we are actively building around. Happy to go deeper on the specifics if you want.
Appreciate the straight answer on the split. The piece I would want before pointing it at Gmail/Sheets: when page content goes to your server for reasoning, is it processed ephemerally and dropped, or retained or logged for any window? And is there a way to scope what gets sent, like a column or field allowlist, so a whole sheet is not streamed when the task only needs two columns?
The Google Docs + Gmail + Sheets integrations are what make this practical - those are the three apps most people actually live in, so hitting them first was the right call. Full DOM interaction is powerful but also where browser agents usually hit walls. Two things I'm curious about: how does it handle sites heavy on shadow DOM or cross-origin iframes? That's typically where this approach breaks down. And is agent context session-persistent, or does it lose memory of what it just did when you close and reopen Chrome?
Lyto
@galdayan Really good edge cases to raise. On shadow DOM and cross-origin iframes, if the page is blocking the DOM reader you can always manually select any element yourself and Lyto works from there. Not fully invisible but it doesn't just break.
On memory, context is session-persistent and stays in your history even after you close and reopen Chrome. It doesn't reset on you.
The browser-as-agent-surface bet is the right one. I have spent a lot of time driving real pages with DOM clicks, so the part I keep landing on is the write side. Reading tabs is low stakes, but once it fills and submits forms in Gmail or Sheets, one misread intent sends the email or overwrites a cell. Is there a confirmation gate on mutative actions, or a preview before it commits? That boundary is what decides whether I would let it touch my inbox.
Lyto
@dipankar_sarkar This is exactly the right question and honestly the boundary we think about the most. Yes, mutative actions like sending an email or editing a sheet go through a confirmation step before Lyto commits. You see a preview of what it's about to do and approve it. We are not going to let it touch your inbox without you seeing it first.
The context-loss problem between tools is the thing that broke me too. I'd start something in Claude, jump to my own product to test it, then back to Claude and it had no memory of why we started. Ended up writing my own context notes by hand like an old engineer keeping a logbook.
The WhatsApp/Telegram angle is smart. Most "AI assistants" still assume you're sitting at a desktop. Curious where it breaks down is the bottleneck the model losing track on longer threads, or is it the user not knowing what to ask for once the agent has full context?
@elias_motionfy The hand-written logbook is exactly the moment we built around. You doing that by hand was the product spec, you just shouldn't have to be the memory.
On where it breaks: it's almost never the user not knowing what to ask. The honest failure mode is the assistant treating every message as if it starts from zero, so the burden of carrying the "why" lands back on you. We flipped that. Lyto keeps its own running sense of what you're doing across threads and surfaces, so when you jump from your product back to the chat it already knows why you left. The surprising part for us was that once the agent actually holds context, people start asking bigger things, the questions get more ambitious because they stop pre-chewing everything for the model. Long threads are still the sharpest edge, won't pretend otherwise, but that continuity is the whole bet.
@gleb_babichev "You just shouldn't have to be the memory" is the tightest way to state that problem I've heard. That's the whole category in one sentence.
The bigger-questions observation is the part I'd not have predicted. Makes sense in hindsight, pre-chewing for the model isn't just annoying, it also caps the size of what you feel comfortable asking for. Nobody asks a fresh-context assistant to reason across their whole week because they know they'll spend more time explaining than getting an answer. Once the ceiling lifts, the questions get more ambitious. That's a compound effect that shows up in the usage data long before it shows up in the demo.
The long-thread edge is honest of you to name. Curious where the current cutoff sits in practice, is it more about context window size, or is it about the model losing signal-to-noise on what still matters vs what's stale? Because those are different problems with different fixes, and I don't think most people realize they're separate.
one agent across browser, tools, and messages is ambitious, that's a lot of surface area to keep consistent. what's been the trickiest part so far, getting it to actually act vs just summarizing/suggesting stuff.
Lyto
@martin_mo Honestly the hardest part is exactly what you said, getting it to actually act rather than just suggest. Anyone can build something that tells you what to do. The gap is closing the loop so it does it. That's where most of our engineering time has gone and still goes.
@arystan_tanekov yeah that gap is brutal ngl, suggestion is basically free at this point, every tool can spit out advice. actually executing means dealing with all the messy real-world stuff, permissions, error states, undoing when it gets something wrong. is most of the engineering time going into the "doing" part itself or more into building trust so people actually let it act unsupervised？
Lyto
@martin_mo Both honestly but if I had to split it, more time has gone into the trust side than I expected. The doing part is hard but solvable. Getting people to actually let it act without second guessing every move is a different problem entirely. You have to earn that incrementally, small wins, visible actions, clear confirmation before anything risky. The unsupervised part comes later once the track record is there.
Refocus
The context-loss problem you describe in the intro is the exact thing I keep hitting building voice AI agents. The moment you move across surfaces, the assistant forgets what it was mid-way through. Curious how Lyto holds that state when it acts inside Gmail or Sheets versus a normal tab. And for the harder-to-undo actions like sending an email or editing a doc, does it confirm with the user first or act and let you roll back?
@igorgurovich State doesn't live in the tab, it lives in Lyto. Gmail, Sheets, a normal tab, they're just surfaces it acts on; the "why" sits one layer above them, so moving between them doesn't reset anything.
On undo, we split by reversibility, not by whether there's a button. Sending an email is irreversible, so it confirms first (shows to/subject/body and waits). Editing a doc is reversible, so it just acts. The rule is: gate the things you can't take back, let the rest flow. Turns out that line is far more reliable than trying to detect every "is this a mutation" event.