We ran Atlantic's early-access program with twelve teams over a three-month window in late 2025. The program was structured as a hands-on deployment: each team committed to deploying at least one agent role in their actual operations, not a sandbox, and to sharing what they learned with us weekly. In exchange, we provided setup support and worked with them directly on any issues that came up.
We expected most teams to start with the Operations agent or the Finance agent, which are the most structurally straightforward. Many did. But three deployments stood out as genuinely surprising in how the teams used the role-based model, and they taught us things about where the approach works best that we would not have figured out from our own assumptions. This post documents those three cases. All descriptions are aggregate and anonymized per our program agreements.
Case 1: The inbound triage system that replaced a part-time hire plan
One team in the program was a 28-person operations software company. They had a growing inbound request volume from their own customers, mostly support and onboarding questions, and they had been planning to hire a part-time coordinator to handle triage and routing. The budget was approved. They were two weeks away from posting the role when they joined the program.
Instead of using the Support agent template as a full-ticket-handling system (which they were not sure they trusted yet), they used it as an inbound classification and routing layer. The agent read incoming support emails and Intercom messages, classified them by type and urgency, drafted an initial response for standard-format questions, and routed everything to the right person on the team with a priority tag attached.
The agent did not send anything autonomously. It prepared work for humans to approve and dispatch. But the preparation work was substantial: by the time a support message reached a human, the agent had already classified it, pulled relevant context from previous tickets, and drafted a response. The human's job was to review and approve or edit, not to start from scratch.
Within 30 days, the team decided to defer the coordinator hire indefinitely. The two people who had been splitting the triage work alongside their primary roles could handle the volume using the agent's output without significant additional time. They did eventually expand the agent's scope to handle some categories of standard questions autonomously, but that came in month two, after they had reviewed enough agent output to trust its judgment on those categories.
Case 2: Contract review routing at a legal services company
A 45-person professional services company that provides contract review work to small businesses joined the program with a different problem: internal routing, not customer-facing work. Their operations team was spending significant time each week receiving incoming contract review requests, triaging them by complexity and type, assigning them to the right internal team members, and following up when turnaround times were getting long.
They configured a variant of the Legal Drafts agent template for internal routing rather than for drafting. The agent's job was to read incoming request emails, extract key parameters (contract type, client industry, estimated pages, urgency signals in the language), classify the complexity tier, and route to the appropriate team member based on capacity and specialization. It also generated a summary of each incoming request in a standardized format that the team member could review in seconds instead of having to read the full email thread.
What surprised us was how much the routing step benefited from the agent's ability to pull structured data from unstructured request emails. Before Atlantic, the ops coordinator was doing that extraction and classification manually for each request. After deployment, the coordinator spent 20 to 30 minutes reviewing the agent's routing decisions each morning rather than doing the extraction work herself. The agent's classification accuracy on the most common request types was high enough within two weeks that she stopped reviewing those and focused her review time on the ambiguous cases.
Case 3: Vendor payment status tracking at a construction technology company
The third case involved a 38-person construction technology company with a large vendor network. Their finance team, which was two people, was spending significant time each week following up on payment statuses: which invoices had been paid, which had not, which vendors needed a status update, and which payment discrepancies needed investigation.
They configured the Finance agent to run a daily payment status review against their accounting system and their email inbox. The agent identified outstanding invoices, checked for any email communication about payment status from the relevant vendor, drafted status update emails for invoices that needed follow-up, and flagged discrepancies where the invoice amount and the recorded payment did not match.
The drafted status update emails were reviewed before sending, but the flagging of discrepancies was treated as autonomous action because the consequence of a flag is just creating a review task, not taking an action. By week three, the finance team lead told us she had stopped doing the weekly manual payment status review entirely and was just reviewing the agent's daily output instead. The time savings were significant enough that she started using the reclaimed time for financial planning work she had been deferring.
What these three cases taught us
The common thread across all three cases is that the highest-value initial deployment was not necessarily the most ambitious one. In each case, the team started by using the agent to handle a preparation and classification layer rather than trying to get it to handle entire workflows autonomously from day one. The autonomous scope expanded later, after the team had reviewed enough output to build confidence.
We also noticed that the teams who got the most value in the first 30 days had a clear champion: one person who understood both the workflow being automated and the Atlantic platform well enough to make configuration decisions without needing to consult others constantly. In the three cases above, that person made most of the scope decisions in the first week, reviewed output daily, and adjusted the configuration based on what they saw. Teams where the decision-making was more distributed took longer to reach the same level of performance.
These cases are not representative of all possible outcomes, and we are not claiming they generalize to all company types or workflow categories. They are three specific deployments with specific contexts. What they do illustrate is that the role-based model's constraint on scope is a feature, not a limitation, for teams figuring out where they trust the agent and where they want to stay in control.
