Your first agent is three steps away

Getting started with Hivemeld does not require a technical background or a weekend of documentation. The onboarding is three steps, and the third one is an agent doing real work while you watch.

This post walks through it, and then through the part that actually determines whether the agent is useful a month from now: the policy you write around it.

Step 1: Name your company

Create an account and enter your company name. That name scopes the workspace — the agents, the backlogs, the action log, and the company data all live inside it, and teammates you invite later join the same one.

That is the whole step. There is no configuration wizard behind it.

Step 2: Pick the role

Hivemeld is built on the idea that agents work best with a defined identity and scope. A general-purpose agent that does everything does everything at a mediocre level. An agent with a role, and a clear understanding of what that role entails, does its specific job well.

The onboarding offers five starting roles:

Sales — account research, outbound, meeting prep, pipeline hygiene
Marketing — content and copy, campaign planning, competitor tracking, the content calendar
Support — ticket triage, response drafting, escalation, FAQ maintenance
Engineering — code review, sprint planning, bug triage, technical specs
Operations — workflow coordination, process documentation, KPI tracking, status reporting

Pick the one that maps to where your week is actually going. Not the most interesting department — the one that is currently costing you the most hours or the most sleep. You will add others later, and you should add them one at a time.

Each role loads with a working prompt and a starter task. You can edit the prompt, but for the first agent, don't. Run it as shipped and see what it produces; you will write a better prompt after you have read one piece of its output than before.

Step 3: Watch it work

The agent deploys and immediately runs its starter task, live. You watch it pick up the task, do the work, and produce output. Not a demo video and not a toy example — a real task executed in your workspace, finishing in a couple of minutes.

Read the output critically. The first one will not be perfect, and that is not the point. What you are checking is whether the agent understood the task and produced something structurally sound: the right shape, the right level of detail, no confident nonsense.

That is the end of onboarding. You have a live agent with a role, a backlog, and one completed task.

The step that isn't in the wizard

Here is where most people stall, and it has nothing to do with the product being hard.

An agent with a role and a backlog will do work. Whether that work is useful unattended depends on a policy you have not written yet: what this agent may do on its own, and what it must bring to you.

Hivemeld's default answer is four conditions that pull a person in:

Spend over a limit. Set the threshold low to start. You can raise it after a month of reading the log.
A new kind of action. The first time the agent wants to do something outside what it has been cleared for, you clear the category. You are approving a kind of action once, not every instance of it.
Low confidence. When the agent's read of its own evidence is weak, it asks. This is the gate worth tuning hardest, because it is the one that earns the others their credibility.
Flagged accounts. Name the customers, deals, or people nothing should touch unattended.

Spend twenty minutes on this per agent. It is the highest-leverage twenty minutes in the whole setup, and it pays out indefinitely, because the alternative is either approving things forever or finding out later.

A useful test after the first week: how many of the decisions that reached you did you read carefully? If it was all of them, your gates are set well. If you clicked through most of them, the gates are catching routine cases and you should move the thresholds up.

Where the work shows up

Two surfaces, with different jobs.

The Decisions inbox holds what the gates produced: the question, which agent is asking, the context, and a place for your answer. Resolve it or dismiss it and the agent carries on. This is the list you check; it should be short.

The action log holds everything the agent did without asking: what changed, what the prior value was, what triggered it, and what evidence supported it. This is the list you read when you want to know what happened, or six months later when someone asks why.

Neither of them is a chat window. Agents are not waiting for you to type.

Assign the second task yourself

Once the starter task is done, give the agent something from your actual backlog. Pick something concrete and reviewable — a task where you can judge the output in two minutes.

For a sales agent: "Build a pre-call brief for the Northrup deal from the email thread and the last two meetings. Flag which MEDDIC criteria have no evidence behind them."

For a support agent: "Read the last thirty tickets, group them by root cause, and draft FAQ entries for the three most common."

For an operations agent: "Audit our vendor list against last quarter's spend and flag anything renewing in the next sixty days."

Then correct what it got wrong — and put the correction in the role prompt or the policy, not just in a reply. A correction that lives only in a conversation gets made again next week. A correction that lands in the prompt never does.

Week two onward

After the first week, add a second task type for the same agent before adding a second agent. Agents reveal work you did not know you were doing, and expanding a working agent's scope is usually a better move than standing up a new one.

Add a new agent when the work genuinely belongs to a different competency, on a different cadence, touching different tools. That is the same instinct that stops a human team from hiring a generalist for every gap.

Deploy your first agent

Name your company, pick a role, watch it work. Then write the policy.

Create your Hivemeld account.

Deploy Your First Hivemeld Agent in Ten Minutes