How Hostinger turned an internal chatbot into an AI agent, and what we learned along the way

If your company has an internal AI assistant, you probably know how this story starts. You launch it, people love it, usage grows, but then it stops going deeper.

That was the case with DEX, Hostinger’s internal AI assistant. People used it every day, but they used it the same way: ask a question, get an answer, move on.

DEX was helpful, but it didn’t change how anyone worked.

So the team pushed past the chatbot stage and turned DEX into something people could build on, from custom agents and persistent workflows to automated reports.

Here’s what happened, what worked, and what’s still a work in progress.

What DEX was: The chatbot stage

DEX didn’t start as an AI tool. Back in late 2024, it was a Slack button where engineers rated their developer experience, nothing more than a survey.

Over the following months, it picked up a few background jobs. It reminded engineers about pull requests waiting for review, nudged people about merge conflicts, pinged them when a postmortem needed follow-up, and said hello to new joiners on day one.

None of this had any intelligence behind it. DEX just watched the workflow and sent the right message at the right time.

The AI layer came in mid-2025. The first version could reply in a Slack thread, and that was about it.

By August 2025, DEX could search our internal handbook, hold conversation context, and handle a few useful tasks. That’s when we started showing it to teams outside engineering.

In autumn 2025, DEX started planning before acting, picking the right tools for each request instead of relying on everything at once.

That made it possible to keep adding integrations without the whole system buckling under its own weight. We connected DEX to Jira, GitHub, Google Docs, analytics dashboards, calendar, incident management, and more.

By early 2026, it was plugged into roughly 30 systems. People across the company used it daily.

But the interaction pattern never really changed. You’d @mention DEX, type your question, get an answer, and close the thread.

The repetition got old fast. If you wanted DEX to summarize your sprint board in a specific format, you had to type the full prompt every time.

If a teammate wanted the same thing, they had to figure out their own prompt from scratch. DEX could handle almost anything you threw at it, but it still waited until someone typed.

If a teammate wanted the same thing, they had to figure out their own prompt from scratch. DEX could handle almost anything you threw at it, but it still waited until someone typed. That was the ceiling.

What changed: Turning a chatbot into an agent

As Mantas Gurskis, Automation Architect and Team Lead on the Delivery Automation Team, put it, the shift to custom agents was “a natural evolution the team saw coming once the chatbot stage hit its limits.”

In early 2026, the team shipped custom agents. Instead of having to repeat their question every time, people could now build a persistent agent that already knew their workflow, preferred format, and defaults.

Three things changed as a result.

People stopped re-explaining themselves

Before agents, every DEX conversation started cold. If people wanted a specific output format, they had to type the full instructions from scratch.

With a custom agent, they write those instructions once. They give it a name, a short command, and their preferences. Next time, they just call the agent, and it already knows what they need.

Generating an infographic with DEX, for example, used to mean typing out formatting and brand specs before even describing what you needed. With those baked into the agent, you just describe what the infographic should show.

Agents started spreading across teams

When someone builds an agent, they can share it with the whole company. For example, someone on the QA team can build a ticket reviewer, and everyone else can use it without writing a single prompt.

That’s how it stopped being a trick for a few people and started becoming part of how teams operate.

As of May 2026, Hostinger has 182 custom agents built by engineers, growth, content, QA, product, and even design teams.

Some agents just run on their own

You can set a DEX agent to run on a schedule. The Emerging Channels Reporter, for example, posts a full weekly performance summary to its team’s Slack channel every Monday morning, without anyone having to trigger it.

The agents that stick around longest are the ones nobody has to remember to use. They just run in the background.

All three changes sit on top of the infrastructure the Delivery Automation Team built, including tool integrations, a plan-before-act routing system, and the agent framework itself. But the layer users interact with stays simple.

You write a set of instructions, pick which tools the agent can access, and you’re live.

The numbers tell the rest of the story. Around 600 people at Hostinger use DEX at least once a week, and 500 of them return three or more times.

DEX handles roughly 17,000 requests per month across 11 departments, including Customer Success and Payments, SEO, and Infrastructure Monitoring.

Between February and May 2026, total usage roughly tripled, growing from around 3,500 weekly replies to over 10,000.

Average replies per user nearly doubled in the same period, which means people aren’t just trying it once and walking away.

What agentic DEX looks like in practice

Talking about agents in the abstract only goes so far. Here are three real use cases built by different teams at different maturity stages.

Automated weekly growth reports

Growth teams run on weekly reports. They track which channels perform well, where traffic comes from, and how that traffic turns into revenue.

Every week, someone pulls data from multiple sources, compiles it into a summary, and shares it with the team. The process looks almost the same every time, which makes it a strong candidate for automation.

At Hostinger, the Emerging Channels Growth team handled all of this by hand.

They tracked performance across Reddit coupon billings and OpenClaw UTM traffic by combining data from two separate Tableau dashboards, manually selecting specific coupon codes, and consolidating everything into one place to see week-over-week results.

The Emerging Channels Reporter connects to BigQuery through Lumos, Hostinger’s internal data analytics layer, and posts a structured weekly summary directly to the team’s Slack channel every Monday morning.

Getting it right took several rounds of iteration. Albert had to resolve attribution overlap with Affiliates, exclude PPC and Influencer traffic, and validate the numbers against TROI dashboards before the output became trustworthy.

The Lumos preview feature helped speed that up by showing exactly how each Slack summary would look before going live. Once the output was accurate, the agent fully replaced the manual process.

The team no longer adjusts or corrects anything by hand, and someone can also trigger the report manually when they need data before Monday. Since each team member’s channel uses a different tracking approach, the agent combines all the data into a single view.

It’s now the only source of truth for the Emerging Channels Growth team.

Automated DRI rotation

Most teams that run on-call schedules or rotating responsibilities handle assignments manually. The method differs from team to team, but the coordination headache is the same.

At Hostinger, some teams sorted members alphabetically and went down the list week by week, cycling back to the top once everyone had served.

Others used an online spinner that randomly picked someone, excluding whoever had just been DRI so the same person wouldn’t get picked two weeks in a row.

Either way, it was all manual. With the alphabetical approach, everyone had to remember when their turn came up. With the spinner, someone had to run it every week, exclude the right person, and announce the result. Both methods broke in different ways.

With the fixed order, if someone was off on their assigned week, sometimes the assigned person arranged a swap in advance. Sometimes the next person in line stepped in. Sometimes nobody remembered to sort it out until someone noticed the DRI was unavailable and a volunteer had to step in.

With the spinner, if someone who was off got picked by accident, the team had to spin again. Someone still had to own the process of running the rotation every week.

Mantas Gurskis and the Delivery Automation Team built DRI Rotator within DEX to handle this process. The tool picks the next person on schedule, updates the Slack group tag so it always points to the current DRI, and posts a notification to the team’s channel.

If someone is going to be out on their assigned week, they can trigger a one-off swap without disrupting the rest of the schedule. Teams across Hostinger have started using it, and the rotation keeps running whether anyone remembers or not.

Closing Jira tickets on release

Development teams track their work in Jira, and when code ships, the tickets tied to that release need to be marked as “Done” so the board reflects what’s live. It’s a small but necessary cleanup step after every release cycle.

At Hostinger, the WordPress team handles this on a weekly rotation. The person on rotation cross-references the GitHub release with the matching Jira tickets and closes them one by one, typically 10-20 tickets and 15-30 minutes of manual clicking per week.

Miguel Pérez Pellicer, a Senior WordPress Developer on the team, built a DEX agent to take over this process. The WordPress Jira Ticket Closer connects to both GitHub and Jira, matches released code to its corresponding tickets, and automatically closes them.

Miguel chose a DEX agent over a traditional script for a practical reason.

The agent is still in its first testing cycle and hasn’t gone through a full release yet. But even at this early stage, it’s catching edge cases that only show up in practice.

One example is when there’s no release in a given week, and the agent still picks up previously closed tickets and includes them in its summary. Miguel is tweaking the prompt to filter those out.

That kind of iteration is typical. The agent works, but the edges need smoothing, and the only way to find them is to run real tasks through it.

What we’re still figuring out with DEX

The shift from chatbot to agents didn’t go smoothly across the board.

• Acting is riskier than answering. When DEX was only answering questions, a wrong response was easy to shrug off. You’d just look it up yourself. Miguel’s ticket-closing agent, for instance, transitions Jira issues and closes tickets across multiple WordPress repositories on its own. A wrong action there is harder to undo than a wrong answer, which is why he’s still running the agent through a testing cycle before letting it touch real releases.
• Getting AI to say “I don’t know” is harder than it sounds. According to Mantas, one of the biggest ongoing challenges is hallucination. DEX sometimes gives a confident answer when the right response would be, “I don’t have that information.” For a chatbot that answers questions, a hallucinated response is merely annoying. For an agent that acts based on its own understanding, it’s a much bigger problem. Getting DEX to be honest about its limits is still active work.
• Agent prompts take more iterations than you’d expect. The first version of an agent’s instructions rarely works the way you want. Both Albert’s weekly reporter and Miguel’s ticket closer underwent multiple rounds of tweaking before the outputs were reliable. The loop is always the same: run real tasks, find where the agent drifts, then tighten the instructions. There’s no built-in way to measure whether a prompt change improved things, so it’s still trial and error.
• Some integrations come with real constraints. DEX can’t read private Slack channels. Some tools are restricted by team or role, so a shared agent might not work for everyone who tries it. Rate limits are shared across all agents, so heavy usage by one can slow things down for others. When teams run into these, they can flag them through DEX’s built-in feedback loop, and the Delivery Automation Team evaluates what to prioritize next.

What this means for any team adopting AI internally

DEX didn’t start as an AI project. It started as a feedback button, grew into a background helper that watched workflows and nudged people at the right moment, and only added intelligence after it already understood the workflows it was part of.

That sequence made the results possible. Albert’s growth report uncovered 40% of untracked performance because DEX was already connected to the data sources his team relied on.

DRI Rotator eliminated weekly coordination overhead because DEX was already embedded in the same Slack channels where rotations happen. Miguel’s ticket closer is still in testing, but it builds on integrations that were already in place.

More than 180 custom agents now run across 11 departments company-wide, and usage tripled between February and May 2026. Teams built almost all of them on their own.

For teams considering something similar, the sequence matters. Understand the workflow first, then let the people who feel the friction do the building.

DEX keeps growing, with new agents showing up every week and more integrations on the way. What comes next will be shaped by problems nobody has identified yet.