Editor’s note: the customer’s name, and details that could identify them, are obfuscated for privacy. This case study is adapted from a real engagement and illustrates a real-world deployment of Fleet.
The customer
A healthcare organization. They operate under HIPAA, and they hold government contracts — which puts their security bar somewhere past “regulated” and into “audited.” Patient data, client data, contractual obligations to government customers: security is not a feature they shop for. It is the constraint every other decision has to fit inside.
Organizations like this don’t get to move fast and break things. They get to move carefully — and they still have to move.
The problem
Their workforce wanted what every workforce now wants: frontier models, and agents that use them to do real work. Analysts wanted reports built without a two-week backlog. Engineers wanted review help and boilerplate off their plates. An internal R&D group wanted landscape scans that took an afternoon instead of a quarter.
The standard path — SaaS AI tools — was a non-starter. Where does the prompt go? Who retains it? Is there a business associate agreement? Can procurement get the data-handling answers in writing? For an organization answering to both HIPAA and government customers, “trust us” does not clear review.
And the alternative to approved tooling isn’t no AI. It’s shadow AI: staff pasting work into personal accounts that no security team can see. The question was never whether AI enters the organization. It was whether it enters through a door they control.
They also knew they didn’t want one chatbot. Different teams have different workflows, different data, different stakeholders. They wanted agents tailored to specific functions of the business — built for their clients and patients, not adapted from a generic assistant. Building that platform in-house meant a team they didn’t have and a maintenance burden they didn’t want.
What they deployed
Fleet, through our enterprise infrastructure buildout: our team provisions the platform with theirs, inside their own cloud account, against their security requirements — then hands over the keys.
The architecture is what made it survivable for their security review:
- Their cloud, their boundary. The entire platform runs inside their cloud account. There is no shared SaaS control plane and no vendor console sitting between them and their agents.
- No public endpoints. The platform is reachable only through their private network and their identity stack. Nothing is exposed to the internet that doesn’t have to be.
- Scoped identities per agent. Each agent holds credentials for exactly what its job requires — and nothing else. The reporting agent reads the warehouse. The coding agent writes to repositories and CI. Cross-agent, the permissions don’t overlap.
- A full audit trail. Every agent action — chat, tool call, repository write, query — is logged, attributable to the agent identity, and reviewable by their security team.
- Model access under contract. Frontier model traffic flows only through providers their compliance requirements accept, under agreements that meet their obligations.
Security here is structural, not advisory. The agents don’t follow a policy about which data they may touch; the permissions simply don’t grant more than the job needs.
Three agents, three jobs
The coding agent
Augments their existing engineering team. It picks up well-scoped implementation work — tests, refactors, internal tooling, first-draft features — opens pull requests, and pushes its work through the same CI and the same human review as everyone else.
That last part is the point. The agent didn’t get a side door; it got a seat on the team, which means the team’s quality gates apply to it. Velocity and quality both moved, and they can see it in their own engineering metrics — review cycle time and first-pass approval rates — not in vendor slides. The agent raises the floor; the engineers still set the ceiling.
The reporting agent
The organization runs on a Redshift data warehouse that consolidates business data from systems across the company — operations, finance, contracting. The reporting agent builds reports and business-intelligence views from that warehouse: recurring deliverables on a schedule, and one-off views when a stakeholder asks.
Before, a report request meant a ticket, a queue, and a turnaround measured in days. Now the stakeholder asks the agent in the channel where the question came up, and the data view arrives with the query and the numbers it was built from. The warehouse’s own access controls govern what the agent can see, and every query it runs is attributable.
The research agent
Used by their internal R&D department to build and scope new opportunities — for the business and for its clients. Given a direction, it surveys the landscape, consolidates what’s known, and produces a scoped brief: the opportunity, the open questions, what it would take to evaluate. What used to be a multi-week scanning exercise before a decision could even form now starts with a reviewed brief in days.
R&D still makes the calls. The agent compresses the distance between a hunch and a decision-ready picture.
Microsoft Teams is the front door
All three agents interact with stakeholders through Microsoft Teams — the tool the workforce already lives in. Each agent is a teammate in the channels relevant to its work: @mention it, and it picks up the task; on a schedule, it posts its deliverables; when it needs a decision, it asks where the people already are.
This is not a small thing for adoption. No new portal, no new login, no training deck. An analyst who has never read a line of documentation can still get a report, because asking an agent looks exactly like asking a colleague.
What’s next
Three agents are live. Several more are planned over the next few months — and because the platform is already built out in their account, each new agent is a matter of configuration: scope its identity, wire its channels, define its job. The first agent took an infrastructure project. The fourth will take a design conversation.
That trajectory — from deployment to inventory — is what Fleet is for. One platform, owned end to end, that turns “can we use AI here?” into an ordinary capacity decision instead of a security exception.
If your organization carries a compliance posture that most AI tooling won’t survive — HIPAA, government contracts, auditors with opinions — that is the environment Fleet was built for. We’d like to show you what it looks like in yours: hello@bold.black.