How we built Harbor, our internal AI agent platform

Harbor is an internal platform that builds and runs AI agents for the whole team. Product, GTM, marketing, sales, community and customer success all have agents, and most of them were built by the person who needed them rather than by an engineer.

However, Harbor didn’t happen overnight. In fact, it took three attempts to get it right. Here’s how we did it.

The problems before Harbor

We started the way you'd expect: someone asked for an agent, engineering built it, we deployed it on its own, and it did one job.

The best of that early batch is still running. When someone signs up on our website, an agent looks them up, pulls the company domain, checks whether they fit our ICP, and if they do, creates a deal and tags the right person on our team.

The problem wasn't the agents, but rather that every new one came through the engineering team. Everyone across the company had a list of things they wanted, and eventually it became too much for any one person to take on.

At first, we tried an open-source agent platform, but it was built for developers, with no realistic way for a non-technical person to build an agent through the UI.

Not to mention it was pricey, quiety charging us tokens while loading its own instructions into every agent’s context window. In the end, we found almost nobody used it.

So, to make sure we had enough agents in place to support across all departments without putting too much strain on the engineering team, we build Harbor.

How Harbor works

Every agent in Harbor follows the same logic: something triggers it, it does one job, and it puts the result where the team can see it.

A trigger, such as a schedule, an event or someone asking in Slack, starts the agent. Then, using a system prompt, relevant tools and an LLM, the agent runs.

It reads shared context from Notion, where we keep our voice guides, ICP and segmentation docs, and reaches our data in Attio, Gmail and BigQuery. When it's done, it moves on to Slack, where it’ll post to a channel, draft something in your inbox or update the CRM.

How to build your own agent platform

We're not open-sourcing the code, but there's nothing in the architecture we'd hide. Here’s how we’d build it again.

1. Keep instructions out of the code. Users should be able to configure an agent’s system prompt and individual task instructions directly in the platform. Reusable skills should sit separately so they can be shared across agents. We use Notion for that last part today; eventually, it’ll need a proper skills library.
2. Have one runner with swappable runtimes. With this, all you need is an agent, a set of tools and somewhere to execute the prompt, making it easy to choose the best model and harness combination for each agent.
3. Use Slack as the default interface. Your team can use Slack to prompt your agents, and in turn agents can use Slack to share results. Skip this and you’ll end up building a UI nobody logs into.
4. Share the tools your team uses with your agent. As well as Slack, sharing your CRM, email, notes and internal data creates context the agent can work with.
5. Finally, add your triggers. Start with schedules as they cover a lot of workflows, before adding event-driven triggers when you have an event worth responding to.

What a Harbor agent looks like in practice

Let’s take the agent Tamatoa, which our Product Lead, Youssef, built to manage product requests. It listens to every customer call across teams, pulls out feature requests and bug reports, and cross-references them against the backlog and codebase to work out if the suggestion is already in the pipeline. Each one lands in his triage queue as a ticket with the customer's name attached, and as a Slack summary at the end of the day.

Before Tamatoa, a customer signal only survived if whoever was on the call remembered to relay it. Now, every request carries the customer who asked for it, so the team can go back to them for context before building, close the loop when it ships, and see how many people have asked for the same thing. And since launching two months ago, Tamatoa has captured and triaged 635 requests.

Here’s how we’ve used agents in other contexts:

• Sales. Nemo searches the web every Monday for fresh UK and Irish raises from pre-seed to Series A. It verifies each one against credible sources, checks Attio to see whether we've spoken before, adds the net-new matches as prospects, and posts a digest to Slack with the founders' LinkedIn profiles and the best channel to use to contact them.
• Go-to-market. Jeremy, our Head of GTM, has an intro chaser that tracks every referral from an investor or partner. It notes how many times he's reached out and how many follow-ups he's sent, adapting its sequence to how each person re-engages.
• Marketing. Tessa, our CMO, has a market-research agent that shares trends across AI, fintech and UK and Irish startups, as well as competitor moves, content ideas and positioning notes. A second agent, Flow, picks up the output and ideates on content campaigns to add to the backlog, and a third agent, Murdoch, publishes content to channels.

The choices that keep it cheap

On average, we use Harbor to execute 450 tasks issued by 10 different users, and at approximately $0.75 a task, our total spend with Harbor is $338. Add on hosting fees, and a month’s spend with Harbor is $370.

A vertical stack, on the other hand, costs an eye-watering $7,090 to perform the exact same tasks — almost 19 times more than Harbor.

The main differentiator in cost comes down to where we buy our tokens from. Since Harbor does everything we need it to do, we’re able to pay our model providers directly.

If we were to adopt a vertical stack, we’d need to pay four different platforms for the same tokens, resold to us at a higher cost. We’ve effectively saved ourselves over $6,000 by cutting out the middleman.

But that’s not the only thing we did to keep our costs down. Here’s how we made sure that by building our own agents, we weren’t breaking the bank.

Put an agent on the cloud only if it has to run without you

Hosting agents on the cloud can be costly, so only put the ones there that need to run round the clock. Not every agent needs to be live all the time, so the ones that you use for one-off analyses or weekly tasks can be kept local.

Keep the model swappable

Since the workflows, tools and instructions all sit outside the model, changing which model runs a job requires a reshuffle rather than a rebuild, and ensures that our costs aren’t tied to one company’s pricing. At the time of writing every agent runs on Claude, with simpler jobs running on cheaper models, and we always have the option to move away if the price spikes.

Don’t make agents relive context they don’t need

An agent running inside Harbor doesn't need to be told it's inside Harbor, or carry a map of every other agent. If not deliberately removed from the agent design, the costs can quickly add up before you even realise.

The case for building over buying

There were a few reasons why building our own software beat out simply buying one.

Buying software doesn’t buy adoption

A big part of our building process was driven by how people would use the agent, and how easy it would be to incorporate into everyday processes. Unlike off-the-shelf software that needs to be accomodated, Harbor can be shaped around workflows that already exist.

We can move at our own pace

The AI stack is changing too quickly for us to wait for a vendor’s roadmap, and if a better model or harness comes along, we want to adopt it immediately. Having our own software keeps our tech stack agile.

It’s integral to company infrastructure

We don’t see the agent layer as another SaaS tool, but rather as integral to the operation of an AI-native company. With influence over how work gets defined, how agents access company context, how tasks are executed and how humans interact with them, we’re comfortable treating the agent layer as internal IP.

It’s a valuable learning curve

As we’re building a financial plaform for companies operating in the AI era, understanding how agents work from the ground up is crucial to Seapoint. Understanding where agent costs come from, how model economics affect workload and how AI spend can be controlled is beneficial to both us and our customer base.

This doesn’t mean you need to build everything yourself. Underneath Harbor, we outsource models, APIs and SaaS to carry out business-critical functions. But we think the layer that decides exactly how the work gets done is one worth owning.

What we deliberately haven’t built yet

Harbor is deliberately incomplete. There are things you’d expect to find in a mature agent platform that we haven’t built yet, because so far we haven’t needed them.

• We don’t have automated evals or regression testing. Every run is logged and can be inspected and debugged, but we still rely on humans to notice when the quality of an agent’s output drops.
• We don’t have native multi-agent orchestration. An agent can run a task on a schedule or respond to an event, but you can’t yet build a workflow where one agent finishing automatically triggers another.
• There’s no shared skills library yet either. There isn’t a straightforward way to package a useful behaviour as a reusable skill that anyone can add to another agent, but this will be a next step.
• There’s no agent catalogue or search system. With a small team, we simply haven’t needed one so far.

None of these would be particularly difficult to add. The important thing is that we haven’t added them before we needed them.

What we’d do differently

If we had our time again, instead of starting with the platform we’d start by making it possible for people to build their own agents.

So if you're doing this, start with one agent, for one person, doing one job that runs on a schedule. Put its instructions somewhere your whole team can edit, and have it post the result to the channel where that work already gets discussed.

Not only will you learn more than you would from any platform decision, but you'll know within a fortnight whether anyone wants the second one.

To sum it up, one of the biggest lessons we learnt from building Harbor: build infrastructure for the company you have today, not the one you imagine you’ll have in future.