ML LABS rebuilt the corporate website of a publicly listed medical technology company from scratch. After launch, the people approved to change its site stopped routing requests through a person. They wrote each on the page itself, in the GreatFeedback.ai widget, and ML LABS' agents applied it, complex ones included. Most changes were live within a minute, with nobody standing between the person asking and the work itself.

Approved Changes Live Within A Minute
- Requests from approved people went live within a minute in most cases.
- ML LABS' agents applied them, complex requests as well as simple edits.
- Nobody relayed a request, so none waited in one person's inbox.
- Visitors could still comment; their feedback went to review instead.
The usual loop for a website change runs through a person. The client writes an email, the engineering lead reads it and asks what was meant, writes it up as a task, someone builds it, and the lead checks and replies. Each hop adds a wait and a chance to lose the detail that mattered. Here that person was Omar, and every change passed through him.
That loop was removed entirely for the people the company trusted to change its site. They no longer needed a meeting, a ticket, a call or a long email thread to get a single change made. They asked on the live page where they saw the problem, whenever they saw it, and the request went straight to the agents that then make the change.
"This is much better than Wix!" — Isabella Schmitt, VP, Clinical & Regulatory Affairs
Requests Captured Where The Problem Is
A change request is only as good as the context it arrives with. An email saying "the About photo looks wrong" leaves open which photo, at which screen size, and what "wrong" means. Most of the back-and-forth in website work is spent recovering that context.
The GreatFeedback.ai widget sits on every page. A person opens it, picks a category, writes what should change, and can point to the element they mean, attach a file or record their screen. The page address and screen size travel with the request without anyone typing them. The request arrives complete, so the work can start on the first read.

Approved People Change The Site; Visitors Only Comment
Speed is only safe when it is limited to the right people. The company named the people allowed to change its website, and only their requests reach the agents. Everyone else who opens the widget can leave feedback and nothing more: it is collected in the GreatFeedback.ai inbox and reviewed, never applied automatically.
The split gives each group what it needs. Trusted approvers get changes live in about a minute, without waiting on a person in the middle. Everyone else gets a simple way to be heard that cannot alter a public company's website, so a stray, mistaken or hostile comment stays a comment until a person on the team decides what to do with it.
Agents Apply Each Request, Complex Ones Included
An approved request goes to ML LABS' agents with its page, screen and files. The agents read it through the product's agent interface, make the change in the website's code, and record the fix against the request it answers. A one-word text edit and a complex request take exactly the same short path: read, changed, checked, deployed.
What the agents removed is the relay, not the judgment. Nobody has to translate a request into a task, because the request says what to change and where. The person who carried each message between the client and the build now works on what needs a person.
Speed Without Skipping The Checks
Faster changes are worthless if they break the site. Every change the agents made passed its checks before it was deployed, so the speed came from removing the waits between steps, not from removing checks. The live website of a publicly listed company is read by patients, clinicians, partners and investors, and it must be correct the moment it changes.
DORA's research on software delivery treats lead time for changes, the time from a commit to it running in production, as a core measure of delivery performance, alongside how often changes fail. The relay sat before that clock even starts, in the wait between a person asking and the work starting. Removing it shortened the path from a request to a live change, while the checks that keep failed changes down stayed exactly in place.
The Same Loop For Your Website
The pattern is not specific to medical technology. Any team that depends on one person to relay its change requests has the same bottleneck, and the same fix: capture the request where the problem is, with its context, and let agents apply it for the people you approve.
GreatFeedback.ai is built and operated by ML LABS, and it runs the same way on your site. If your website changes wait on a person in the middle, a first call is where to map your own loop and see which requests could go live straight from feedback.
References
- DORA. DORA Research Program. DORA, 2024.



