At HIVED, AI has not changed what we are trying to achieve. We still want to move faster, build smarter and remove friction wherever it exists. What has changed is who gets to do that work.

Problems that previously required engineering time can now be solved by the people closest to them. The challenge is no longer whether something can be automated, but how to enable that safely, consistently and at scale.

That is what our newly formed AI & Automation function (AI&A) exists to do. This blog sets out the principles we have landed on, the infrastructure we have built, and what we have learned so far.

We have always built, not bought

Before AI&A existed as a function, HIVED was already a heavy user of Make.com, Airtable, Retool and other low-code tools. For internal dashboards, operational workflows, metric reporting, and customer communications, a lot of it was assembled by the people closest to the problem rather than by an engineering team writing custom software.

HIVED is a fast-growing business with finite engineering capacity. The alternative to low-code was often either waiting in a backlog or not solving the problem at all. These tools gave us a way to make progress on the long tail of issues that mattered enough to fix, but were not worth pulling engineers away from core infrastructure for.

That history matters because AI did not introduce a build-it-yourself culture at HIVED. It arrived in a business that already had one.

AI has a marketing problem

A lot of what people are excited about doing with AI is not really AI, but automation. What AI has done is make automation accessible to people who could not build it before.

We have a fleet admin who handles occasional operational tasks, such as processing a parking ticket. With a parking ticket, the workflow is broadly the same each time: gather the relevant details, enter them into a form, log into the relevant council portal, make a payment, and move the process forward.

What has changed is that the person doing the admin can now build the automation themselves. They do not need to write code or learn a low-code platform. Instead, they can describe the process in natural language and end up with something genuinely useful.

That changes the economics entirely. The long tail of small but valuable operational improvements that were never worth direct engineering investment suddenly becomes viable. More importantly, the people building those solutions are often the people who understand the problem best, because they are the ones dealing with it every day.

Automation is also a forcing function

There is a side effect to all of this that does not get talked about enough. To automate something, you first have to describe it. In a fast-growing company, a surprising amount of operational knowledge lives in someone's head, a Slack thread from eight months ago, or a process nobody has revisited in years. Describing a workflow to an LLM forces it into the open.

Once a process is written down, it can be questioned. Why does this step exist? Why does this need three approvals? Why is there a manual handover here at all? Often, the outcome is not an automated process. It is a deleted one.

Automation also introduces a level of cost visibility that most manual processes never have. Tokens and API calls have a clear cost per run. The cost of individual manual tasks is usually hidden inside broader operational activity. Automation itemises it.

A fair amount of what looks like AI rollout work is, in practice, process-cleanup work. We are finding workflows that have existed for years simply because nobody stopped to question them. Bringing those processes into the open has forced us to do exactly that, and not every process survives the exercise.

A framework for safe experimentation

There is a new AI tool launching every week. Locking too deeply into any single platform would be a mistake, given how quickly the landscape is evolving. We have deliberately kept our stack small and flexible, with the expectation that any tool could be replaced if something better comes along.

As a Google Workspace organisation, Gemini is the default AI tool for day-to-day tasks. Claude handles more complex workflows and shared team context, while Make.com acts as our automation layer. Airtable, Retool and Supabase support structured data, dashboards and lightweight internal applications.

More important than the tools themselves is how they are used. Claude is well-suited to getting an idea up and running. You can iterate on a workflow, test whether it actually solves the problem, and refine it quickly. Running every workflow through an LLM indefinitely, however, is expensive, non-deterministic and difficult to observe.

Once an idea has proved itself, we move it to Make. Make provides scheduled runs, observability, controlled credentials and a reliable execution environment. Some workflows still call out to an LLM for a specific step, but the LLM is no longer orchestrating everything. Deterministic processes run deterministically.

Governance that enables, not restricts

Giving people the ability to build automations is relatively straightforward. The harder challenge is doing so without losing visibility of what exists, who owns it, what data it can access, and how much of the business depends on it.

The risk is the same capability viewed from a different angle. Someone builds a workflow that quietly becomes business-critical, then leaves. No one knows it exists until it breaks. Someone connects an AI tool to a system it should not access, or a well-intentioned automation ends up handling data it should not. It is shadow IT, just faster and harder to detect. The question is not whether to give people these tools. The question is how to do so without losing visibility of what has been built.

We operate with a defined set of approved tools, not to limit experimentation, but to ensure we understand what is running and whether it is appropriate for the data it handles.

Alongside that sits an automation registry: a single source of truth for every automation we run. It syncs directly from Make, meaning registration largely happens automatically. Every automation has an owner, a risk tier, a list of dependencies, and a description of its purpose. If it is not in the registry, it does not exist.

We also classify automations by risk. At one end are workflows that, if they fail, have a direct operational impact. At the other end are automations that can quietly fail for days before anyone notices. The tier determines the level of review required before launch and how loudly the system escalates when something goes wrong. Anything touching sensitive data, writing to core systems, or carrying multiple dependencies is automatically treated with greater scrutiny.

As AI lowers the barrier to building, the importance of visibility, ownership and accountability only increases.

Observability: trust, but verify

A registry tells us what exists, while a tiering system tells us what matters. Neither, however, tells us whether anything is actually working.

Every automation should be visible to someone, and the level of visibility should reflect the level of risk.

For critical workflows, we pipe execution data from Make into Grafana, giving us real-time dashboards, alerting, and clear ownership when something breaks. Queue lengths, failed executions and slow scenarios act as early warning signals, allowing us to spot issues before they reach a driver or a customer. If a critical workflow fails, we want to know within minutes, not when someone files a complaint.

Lower-risk automations require a different approach. Rather than introducing another dashboard, we route alerts directly to the person or team responsible for the workflow. Their automation, their alert.

The distinction matters because observability should scale with impact. Critical systems receive the visibility they need, while lower-risk workflows remain visible to their owners without creating unnecessary noise for everyone else.

If you're a Make user and want to go deeper into the technical side of this, FINN has written the poster child piece on monitoring a Make instance, and we've drawn some of our of inspiration from it.

Rock pools for vibe-coded apps

Make handles most of what we need to build, but some workflows require an actual interface: a form, a dashboard, or a lightweight internal application. While the barrier to building these has fallen dramatically, the challenges tend to begin after the prototype, when questions of hosting, authentication, deployment and maintenance start to matter.

Our approach is to provide a paved road. The hosting is already there (S3 bucket), the database is already in place (Supabase), and the deployment pipeline runs through GitHub with code review before anything reaches production. Crucially, this infrastructure is isolated from our core systems, meaning experiments cannot interact directly with parcel scanning, sortation, routing or the tracking page.

We call this environment a rock pool. Our core systems are deeply engineered, heavily reviewed and directly connected to the delivery experience. A failure there affects customers. A failure in a rock pool means an internal team has a slightly worse afternoon.

That separation gives people the freedom to experiment, while ensuring the risk stays contained. Internal tools can evolve quickly without every prototype carrying the same operational consequences as production software. This is mostly used by AI&A and a handful of others comfortable with the basic engineering rhythm of branches, PRs and reviews.

Champions, not central builders

AI&A is a small central function, and while it will grow over time, the goal is not to have a representative in every team meeting. The rollout only works if ownership exists throughout the organisation.

That is why we have champions: people embedded within each function who act as the local point of contact for AI and automation. They spot opportunities, share what is working, help new ideas land, and feed patterns back to AI&A. They are the connective tissue between the central function and the rest of the business.

They are not full-time builders, nor are they expected to become technical experts. The role can rotate. What matters is their understanding of the work itself. A Commercial champion understands the day-to-day realities of Commercial in a way AI&A never will. They know where the friction is, what is slowing people down, and what would actually be useful.

AI&A provides the tools, infrastructure and guardrails to build safely. The champions provide the context. That combination is what makes a rollout land.

Where this goes next

For us, the goal is not to centralise every decision or control every automation. It is to give people the tools to solve their own problems, while building the infrastructure, visibility and guardrails needed to do so safely.

If there is one lesson we have learned so far, it is that the hardest part of an AI rollout is rarely the technology. Half the tools we use today might be different ones in twelve months, but we are providing the conditions for our team to solve their own problems, without losing sight of what has been built.

For more on how we use AI at HIVED, check out our blog on AI Coding. You can also follow HIVED on LinkedIn for more on HIVEDmind and how we continue to enhance our tech-enabled delivery network.