This morning I read TechCrunch’s write-up of Ema’s $77M raise, the one headlined “AI starts eating into enterprise software and services.” The money didn’t stick with me as much as a boring question did: how does the AI employee actually get into Salesforce? As I understand it, Ema’s pitch is a platform of AI agents that take over chunks of enterprise work across the apps a company already runs. It’s a big bet, and I don’t doubt the models can handle the work. But an AI employee is still an employee in the HR-onboarding sense. I think an AI browser agent running in your own signed-in Chrome gets to skip most of that onboarding.

Every new hire needs a badge first

When a person joins a company, IT spends a week handing them things: an Okta account, group memberships, a Salesforce license, a Workday role, a VPN profile, and access to whatever internal admin tool the ops team built in 2019 and never documented. An AI employee needs the same list. The difference is that it can’t click through an SSO prompt or approve a push notification on a phone, so every item becomes a service account, an OAuth app registration, an API scope negotiation, or a connector that someone has to build and then maintain each time the vendor changes its API. So rolling out an agent platform at a big company is mostly integration work, and integration work has a queue. I’ve seen security review queues at mid-size companies stretch to six weeks for one new OAuth app (and that was an app with a SOC 2 report and a friendly sales engineer). Multiply that by every tool in the stack. The connector backlog turns into the product roadmap whether anyone planned it that way or not. And internal tools are the worst of it, because no vendor is writing a connector for the admin panel your platform team built on Retool, which may not have an API anyone outside would touch anyway. I wrote about a version of this in Onboarding an AI Teammate Means Handing It Logins It Can’t Use, and Ema’s raise doesn’t change the shape of the problem. It just puts a bigger number on it.

Three tasks, and what each one needs before it can start

Here are three ordinary tasks, written as the setup each approach needs before it can take its first action.

A Salesforce update: a rep finishes a call and needs to move the opportunity to Negotiation, push the close date two weeks, and log a note.

  • Agent platform: a connected app, an integration user (which can cost a license depending on your edition), field-level permissions set by an admin, and a decision about whose name appears in the activity history.
  • Browser agent: the rep already has the opportunity open. The agent reads the page, fills in the fields, and the edit is logged under the rep, because it’s the rep’s session.

A Workday form: a manager needs to file a job change for someone on their team.

  • Agent platform: an Integration System User, security groups that usually only a Workday admin can set up, and an HR team that is (rightly) nervous about giving a bot write access to company-wide payroll data.
  • Browser agent: you’re already signed in through SSO, and Workday only shows what your role allows. The agent can’t see anyone else’s salary because you can’t either.

A ticket in an internal admin panel: support needs to issue a refund and open a ticket in a tool that sits behind the VPN and Okta.

  • Agent platform: probably a custom connector, maybe a new API endpoint, a network path from the vendor’s cloud into your private network, and a conversation with security I would not want to have.
  • Browser agent: it’s a web page. The agent reads the form, fills it in, and asks you before it clicks submit.

That last pattern is roughly how Dassi works. It’s a Chrome extension in the side panel that acts in the tab you’re already looking at.

The AI browser agent inherits your permissions, mess included

That’s the whole point, and it’s also the catch. If your Salesforce role has too many permissions, so does the agent. It won’t clean up bad access hygiene. It just avoids adding another identity on top of it.

It stops when you close the laptop

The obvious gap is that an in-tab agent runs only while your browser is open and you’re around, more or less, to watch it, so if you close the lid, it stops. Ema’s model, where an agent works through a queue of 400 invoices at 2 a.m. with nobody watching, isn’t something Dassi does, and I don’t think it should pretend otherwise. For overnight batch work across thousands of records, a proper integration with a service account is the right tool, and that security review is probably worth sitting through. But a huge share of enterprise work isn’t batch work at all. It’s one person, one record, three tabs and twenty minutes, repeated forty times a week, and for that kind of work the connector backlog is pure overhead. Sessions expire too: if Okta signs you out at lunch, the agent is signed out as well and you log back in like you always do. That’s annoying as hell, but it’s the same annoyance you already live with.

Where I’d put $77M, hypothetically

I don’t think Ema is wrong that AI will take over a lot of enterprise software work. I’m less sure that happens through connectors, one approved service account at a time. Some of it will, obviously. But I suspect much of it will happen in the tab where someone is already logged in, which is harder to raise money for and a lot faster to start.

If you want to try that version, Dassi is free on the Chrome Web Store, and it works with your ChatGPT login or your own API key. Your IT team will still want to know which extensions you’re installing, which is fair. That’s still faster than six weeks.