/services

Services

Hiveframe is the platform: an isolated AWS environment for each client, with its own key, its own secrets, and its own logs. On it, we build four things for each client and run them for you. On the discovery call we work out which of them the client needs and how far each one goes.

1. Semi-autonomous or fully autonomous agents

We build each agent in the mode the business needs. The choice is made per workflow, not once for the whole client.

Semi-autonomous. A person works in a chat client the business already uses, such as Claude or ChatGPT, which connects to our MCP server. The model runs in that chat client and calls our tools in a loop to finish the job. The person's token decides which tools they can call. The tool calls themselves run through one service account per system, shared by everyone using the agent, so what a tool can do is set by that service account, not by the person's own permissions in that system. Keep that in mind when you set up groups: anyone in a group can use its tools at the service account's level of access. This mode fits work like answering questions across systems, drafting reports, or updating records on request.

Fully autonomous. A schedule, script, or system event starts the agent instead of a person. These agents run in the client's AWS environment and call models through Amazon Bedrock. Each one gets its own service account, scoped to its one job. That means you can shut off automated work without touching the tools people use. It also limits the damage from bad input: an unattended agent that gets fed a malicious email can still do only its one narrow job. This mode fits work like routing incoming email and requests, chasing overdue invoices, or routine updates that run on a schedule.

In both modes, steps that change data or reach customers can pause for a person to approve them before they run. Starting a workflow semi-autonomous lets the client see how the agent works before it runs on its own.

2. Hosted MCP gateway and tools

We host an MCP (Model Context Protocol) gateway for each client in that client's own isolated AWS environment. It runs as Lambda functions behind API Gateway, at an endpoint that belongs to that client alone. Connectors are the doors into the client's systems, and every call to them goes through the gateway. Behind it sit two kinds of tools, and both pass the same token check, group check, and logging:

Custom tools we build. Named actions like "look up open invoices for a customer" or "update job status."
Filtered vendor connectors. Where the vendor's own connector is good enough for the job, we use it behind our gateway, limited to an allowlist of the tools the job needs.

Each tool reaches its system through that system's API, its database, its files, or the program itself, using a service account you create. Where a vendor's own connector already covers a read, we put it behind our gateway instead of rebuilding it. Writes go through tools we build.

In the drawing, check 1 is the group check against the client's identity provider, and check 2 is the service account you create for each system.

One tool per job. For example: look up a contact, list a customer's open invoices, or update a ticket's status. A custom tool has a defined input and output, so the agent can't do more than the tool allows. A vendor connector is limited to an allowlist of the tools the job needs, and the rest of what it offers stays off.
Fixed logic in custom tools. The query or API call inside each custom tool is written in our code. It takes specific parameters, like a customer ID or a new status, never a free-form query. The model picks which tool to call and fills in the parameters. It can't reach anything we didn't build or allow a tool for.
Read-only by default. Write access is granted per tool and per group, only where the job needs it. The service account has to allow the write too.
Vendor connectors, read-only. When we use a vendor's connector, we pass through only the read tools the job needs, and it signs in with a read-only service account you create. Even if a write tool slipped through, the system would refuse it.
Service accounts you create. You, or the client's IT, create a service account for each system, scoped to what the tools need. We store its credentials encrypted, with a separate key per client. We never hold admin accounts.
Checked and logged. On every call, the gateway validates the caller's token and checks its groups before the tool runs, whether it's a custom tool or a vendor connector. Every tool call is logged: which tool, who triggered it, when, and whether it succeeded.
Hosted by us. We host, patch, and secure the gateway and our custom tools. Cloud systems need nothing installed at the client, and on-prem systems need only one small tunnel connector, outbound only. Hosting is covered by the monthly care plan.

We connect cloud systems, such as ServiceNow, Microsoft 365, and QuickBooks Online, along with CRM, email, inventory, job tracking, accounting, and billing software. Where the vendor's own connector fits the job, we put it behind our gateway. Where no connector exists, or it reaches further than the job needs, we build a custom tool. If a system has an API we can reach with a scoped service account, we look at it on the discovery call.

Systems with no connector at all

A lot of what a business runs has no connector: a SQL database, shared files, an executable on a server, or older line-of-business software. For these we build custom tools, one per job, and they sit behind the same gateway as everything else: the token check, the group check, a service account you create, and a log of every call. The query or command inside each tool is written in our code, and it's read-only by default.

For an executable, the tool runs the program with a command line written in our code, such as which input file to process and which options to use. The model fills in only the values the tool allows, like the file name.

When the system lives on the client's own network, like an on-prem database or a file share, one small connector on that network (Cloudflare Tunnel) opens an outbound-only, encrypted connection to our tools, so nobody opens an inbound firewall port. A tool that runs an executable is installed on the machine with the program and reached the same way. We look at each system on the discovery call.

3. Agentic RAG built on the business

We build the context the model works from, using the client's own material: what the business does, its products and services, its policies and procedures, and the documents it already keeps.

Agentic retrieval. Retrieval is a tool the agent calls when it needs it. The agent decides what to look up, can search more than once, and combines what it finds with live data from the MCP tools. It doesn't rely on a single lookup made before it starts.
Built from the client's sources. Product and service catalogs, FAQs, procedures, shared drives, and wikis, whatever the client uses.
Stored per client, encrypted. The index lives in the client's own AWS environment, encrypted. It holds the documents the client chose to include, nothing else.

The result is an agent that answers from the client's own information, rather than from general knowledge alone.

We work with the client's identity provider, such as Microsoft Entra ID, Okta, or Google Workspace, and build the system's sign-in and access around it. The client keeps control of the identity provider, its users, and its groups.

App registration. We set up the integration in the identity provider with the client's IT team, often you.
Single sign-on and tokens. People sign in with single sign-on. The identity provider issues OAuth 2.0 access tokens as JSON Web Tokens (JWTs), and the gateway validates each one: signature, issuer, audience, and expiry.
Groups decide tools. Groups in the identity provider map to the tools a person is allowed to call. The service accounts decide what those tools can do in the client's systems.
Revoking access. Removing someone from a group takes away the tools that group allowed. Disabling their account cuts their access entirely.

How they fit together

An agent (1) calls tools through the MCP gateway we host (2), whether they're custom tools or filtered vendor connectors, and works from context built on the business (3). People sign in through the client's identity provider, which decides which tools they can call (4), and the service accounts you create decide what those tools can do. The security page covers the controls in more detail.

After launch, the monthly care plan covers hosting, monitoring, fixes, and model updates. We also adjust the tools as the client's business changes: a new job status, a field they started tracking, a report that needs one more column. See what each tier includes.

Discovery and delivery are fully remote, with no on-site visits.

Book a free 20-minute partner call