Do I need to know what should be automated?

No. Most people arrive with a feeling rather than a specification — something takes too long, or only one person can do it, or it gets dropped whenever the week is busy. That is enough to start from. If you can point at one job you would gladly stop doing by hand, we can work with that. If you can’t point at one yet, start with the free diagnostic instead: it finds the constraint first, and the workflow follows from it.

What happens with the first workflow?

We build it. You describe the job the way you would explain it to somebody starting on Monday — what comes in, what you would check, what should go out, and what you would never let leave without reading it. That becomes a working workflow, connected to the tools you already use, running on your account. You watch it run on real work before you rely on it. One workflow, start to finish, so what you are judging is a thing that works rather than a proposal for one.

What happens after that?

It runs. Keeping it running is the recurring part — hosting, the models it calls, monitoring, and the fixes for when something upstream changes its mind about a field name. Most people then add a second workflow, and it is usually one they spotted themselves while watching the first one work. There is no bundle to commit to up front. The next workflow is a decision you make when you want it, and not before.

Can my team eventually build workflows themselves?

That is the intended end state, and the training exists for it. Once your team has watched a few workflows get built, the skill turns out to be the describing — knowing what the work actually involves and where the judgment sits — which is the part your team already has. Some businesses would rather we kept building, and that is a legitimate choice rather than a failure. Most want at least one person inside who can change something without picking up the phone.

Do I become dependent on hmn.plus?

It is the right question to ask any vendor, and the honest answer is that you can be for exactly as long as it is useful. Three things are deliberate: the workflows are described in plain language rather than locked in a format only we can read, they run on infrastructure that can sit in your own name, and we teach the building instead of keeping it. Being the only people who can change your systems would be a business model. It is not ours.

Can we eventually own the system?

Yes, and it is an option rather than a destination — plenty of businesses would rather we kept running it, and that is a reasonable thing to want. When you do want it, the workflows, their definitions and the infrastructure transfer to you, and your team keeps the training that makes them usable. We would rather you stayed because staying is worth it.

The first automation is a fixed price, so the first decision is a small one: NZ$500 + GST to map it and get it built. After that, the platform it runs on is NZ$150 + GST a month for each person who builds workflows — everyone else who uses it is free — and that covers hosting, running your workflows, monitoring and support. Workflows you build yourself cost nothing extra; the ones we build are quoted one at a time, on what each actually involves. No annual lock-in, and nothing larger to sign before you have seen something of your own working.

Why not use ChatGPT, Claude, Zapier or n8n?

They answer a different question. Chat tools put something capable on the other end of a conversation, and then nothing happens unless a person types — every session starts again, and what the business knows ends up living in whoever writes the best prompt. Zapier and n8n wire apps to each other; the wiring holds until a field name changes, and it never makes a judgment call. Both leave the work depending on a particular person. What we build has a fixed shape: the same steps in the same order, your rules written in, a record of every action and the reason for it, and a person standing where a person should stand. The thinking inside a step can be as sharp as it needs to be. The path through it does not change because somebody phrased something differently. That is the difference between a tool one person is good at and a system a business runs on.

Where should AI actually be used?

On the judgment inside a step, not on the whole step. Reading an enquiry and working out what kind it is: yes. Drafting a reply in your voice, from your own past replies: yes. Moving money, or telling a client something binding, with nobody looking: no. What we build to is that anything with consequences waits for a person, and everything in front of it does not have to. A faster version of a bad process is still a bad process, which is why deciding where AI belongs happens before anything gets built, and is most of the value.

AI agent governance: controls before agents run

AI agent governance is the set of controls that decides who can run an agent, what data it can access, which tools it can use, and how its actions are reviewed. The practical answer is this: govern the workflow before the agent runs, not after something goes wrong.

We built hmn.plus around that belief because most agent risk is quiet. It doesn't look like a dramatic breach. It looks like a useful workflow with too much reach. A sales workflow sees finance context. A support agent gets a tool it doesn't need. A copied workflow carries access into the wrong team.

Trust helps small teams move fast. It is not a safety model. Once agents can use tools, call services and combine context, governance has to be enforced by the system itself.

Why AI agent governance matters

The risk with agents is not that they are mysterious. The risk is that they remove friction.

A person with broad access still has to open systems, search, copy, decide and act. An agent can move through those steps faster. It can also combine data from places a human would not normally connect in one sitting.

That changes the meaning of access.

A customer follow-up agent may need CRM notes and recent support context. That sounds reasonable. But if the same workflow can also read billing records or internal pricing notes, the agent may carry that context into an email draft. No one intended a leak. The workflow was just wired too broadly.

Good AI agent governance answers six practical questions:

Who is allowed to run this workflow?
What class of data can it handle?
Which agents or actors can participate?
Which tools can each actor use?
Which credentials are available in this tenant, profile or team context?
Can an owner review what happened after the run?

If those answers live only in a policy document, they are theatre. They look safe and they aren't. The system has to enforce them.

The governance layer belongs inside the workflow

A workflow should not be only a list of agent steps. It should carry the rules that make those steps safe.

That means the workflow declares the kind of data it handles, who may run it and which actors are allowed inside it. Each actor has a defined tool surface. Each service declares the kind of access it needs. Credentials resolve only in the current tenant or profile.

This matters because workflows have different blast radiuses. A public research workflow and a renewal-pricing workflow should not be treated the same way. One may read public sources and write a summary. The other may handle customer records, commercial terms or internal account strategy.

When governance is part of the workflow definition, the workflow becomes a contract. The system can reject the wrong setup before execution. It does not rely on someone remembering that a certain agent should not be attached to a certain data source.

The simple pattern is:

The workflow declares its data classification.
The workflow declares who can run it.
The workflow restricts which actors can participate.
Each actor gets only the tools needed for the job.
Services reference the type of credential they require.
The actual credential resolves only inside the active context.
A pre-flight check validates the whole setup before the first step runs.

That last point is where governance becomes real. If the system waits until runtime, the agent may already have seen data it should never have touched.

Pre-flight checks stop unsafe wiring early

Most automation failures are not caused by a missing policy. They are caused by a gap between the policy and the running workflow.

We treat pre-flight checks as a hard gate. Before a workflow runs, the system checks whether the actors, work streams, enabled services, service references, tool permissions and role restrictions are allowed together. If the setup does not pass, the run does not start.

This is not glamorous. It is where a lot of safety comes from.

Actor checks

The system should ask whether this actor is allowed to be part of this workflow at all. If a workflow is restricted to certain roles or teams, an agent outside those boundaries should be rejected before it receives context.

Work stream checks

Different parts of a workflow often represent different kinds of work. Research, approval, customer communication and record updates have different risks. If a step is wired into the wrong stream, that is not a harmless technical detail. It can be the path by which one team's context reaches another team's task.

Service checks

A workflow should only call services that are enabled and approved for that context. A disabled service should not keep working because an old workflow still points at it. A broken reference should not fall back to a loose default.

Tool checks

An actor should only see tools that match its job. If an agent is meant to research and summarise, it should not have tools for billing, messaging or record updates. The question is not whether you trust the agent. The question is what actions are reachable.

The payoff is simple. An unsafe combination fails before the agent runs. That is much cheaper than finding out later that the workflow had access it never needed.

Tool permissions should be boring and explicit

AI agent governance often gets described in abstract terms. In daily use, it is mostly boring permission design.

Each actor needs a defined tool surface. Not a general pool of tools. Not access to everything because it might be useful later. A short list of tools that match the task.

Agents don't experience tools like people do. A human may know not to use a finance admin option because it feels out of scope. An agent sees available tools as possible actions. If the instruction points in that direction, the tool may be used.

For a research-style enrichment agent, the boundary should be narrow. It can read approved sources and write findings. It should not update systems of record, send customer messages or trigger operational actions unless that is the specific job. It should also have limits on how long it can keep trying. Open-ended tool loops turn a useful agent into an operational risk.

This is the balance founders should want. The agent is useful. Its freedom is limited. Both can be true.

Credential separation is non-negotiable

Access governance breaks when credentials are treated casually.

In a small internal workflow, it is tempting to wire a service once and assume everyone knows how it should be used. That does not hold when agents run across tenants, profiles, departments or client environments. One context's credentials must not reach another context's run.

The safer pattern is to separate the service definition from the secret. The workflow can say what kind of access it needs. The actual credential is resolved only inside the active context.

This distinction prevents three common mistakes:

Copied access. A workflow template should not carry live credentials with it.
Global overreach. A shared credential should not give an agent more reach than the current run requires.
Late failure. The system should not discover a credential problem after the agent has already started.

If the right credential is not available for the active context, the run should fail safely. That can feel annoying in the moment. It is better than completing the task with the wrong keys.

Audit logs make agent behaviour reviewable

Pre-flight checks reduce risk before a run. Audit logs make the run understandable after the fact.

You need both.

Every agent run should leave a record that an owner can review without reconstructing events from memory. At minimum, that record should show the workflow used, who or what triggered it, the steps taken, the inputs used, the outputs produced, the tools called and where time was spent.

We built this because a final answer is not enough. A clean output can hide a messy path. A bad output may come from a poor instruction, missing context, a slow service, an unavailable tool or an access boundary working exactly as intended.

A useful audit trail answers concrete questions:

Which agent ran?
Which workflow was used?
Who triggered it?
Which tools were called?
What arguments were passed?
What came back?
Where did the workflow stop, if it stopped?

This is not only for incidents. It is how you improve the system. If a workflow is slow, you can see where time is going. If an agent keeps asking for a tool it cannot use, you can decide whether the workflow is badly designed or the restriction is doing its job.

Auditability turns governance from opinion into evidence.

The quiet risk is context drift

The risk founders should pay close attention to is context drift.

Context drift happens when information from one area of the business starts appearing in another workflow without a clear decision to allow it. It can happen through broad retrieval access, shared credentials, copied templates or tool permissions that have grown over time.

It is quiet because nothing obvious breaks. The agent still works. The output may even be more useful. That is why the risk is easy to ignore.

A people-operations workflow should not enrich a manager summary with commercial account notes unless that access has been deliberately approved. A customer-support workflow should not pull from internal pricing strategy unless it was designed for that purpose. A research agent should not write into systems of record because someone might want that later.

Good AI agent governance prevents context drift by making boundaries executable. Data classification limits what the workflow may handle. Actor restrictions control who can participate. Tool permissions define reachable actions. Credential resolution keeps access tied to the current context. Pre-flight checks reject unsafe combinations. Logs make the behaviour reviewable.

A practical AI agent governance checklist

If you're putting agents into a small team, don't start with a committee. Start with the workflow.

Classify the workflow data. Decide whether it handles public, internal, sensitive or restricted information. If you can't classify it, you don't understand it well enough to automate it.
Restrict who can run it. Define the roles, teams or actors allowed to trigger the workflow. Avoid broad access for workflows with sensitive data or side effects.
Limit every actor's tools. Give agents only the tools needed for the task. Read-only agents should not have write tools.
Separate services from credentials. Let services describe the access they need, but resolve the actual credential only inside the active context.
Validate before execution. Check actors, work streams, enabled services, service references, allowed tools and restrictions before any step runs.
Fail closed. If the system cannot prove the wiring is allowed, stop the run. A blocked run is better than a quiet leak.
Log the run. Keep the record needed to review inputs, outputs, tool calls, timing and stopping points.
Review access from behaviour. Use logs to see what agents actually do before expanding permissions.

These basics are enough to make governance practical for most small teams. You can add more controls later. But if these are missing, the system is relying on luck.

What good governance feels like

The best governance is not constant friction. It is clear boundaries that let people move faster inside safe limits.

A founder should be able to approve a workflow knowing it cannot silently reach another tenant's credentials. An operator should be able to run an agent knowing it only has the tools required for the job. A manager should be able to review a run and see what happened without asking an engineer to piece it together.

AI agent governance is not about making agents timid. It is about making access explicit, execution gated and behaviour reviewable.

We built hmn.plus this way because useful agents need boundaries before they need scale. If your system can refuse unsafe wiring before execution, keep credentials tied to the active context and leave a reviewable trail after each run, you have the start of a governance model that can survive real work.