How We Deploy AI Agents Across Our Teams

Summary: JJELLYFISH works with a wide range of clients and consultants. Rather than take the rigid route and prescribe one agent workflow for everyone, we give teams room to build what specific client situations they’re encountering require, and we standardize only the shared rules that keep that work accountable and deliverable standards high: how agents connect to tools, where facts come from, how work is documented, and what still needs a human to approve.

JJELLYFISH is an agency. Our consultants work with founders who are early in building U.S. sales motions across many industries, stages, and product types. The people on those engagements bring different strengths as well - some lean into outbound, some into discovery, some into systems work. That mix is useful. It also means a single, prescribed way of using AI agents would get in the way of the work.

We want people able to serve their clients in the best ways possible. The agents that help one team prep for buyer calls will not look like the agents that help another team clean pipeline data or draft follow-ups. Forcing everyone onto the same workflows would flatten that. Ignoring shared rules entirely would create a different problem: disconnected tools, unclear sources, and work that is hard to review later.

So we made a deliberate design choice. Flexibility stays at the edge, with the person and the engagement. A small set of common standards sits at the center. That center is the spine of how we deploy agents across the agency: the short list of things that have to work the same way no matter who owns the agent.

What we standardize, and why

Four areas matter enough to hold in common.

Connections. An agent should only use access its owner has and has asked for, and those connections should be written down. For a small number of shared outbound tools, we manage access centrally and pull credentials at the point of use rather than leaving them on pages or in prompts. Everything else runs through the person’s own logins. We also run a recurring check that access still works, because silent failures are hard to catch after the fact.

Sources. Agents should be clear about where their facts come from. We are building a map of which systems own which kinds of data, but that map is still a placeholder and is not binding. Until it is, agents describe their sources in plain language and mark gaps instead of inventing answers.

Documentation. Shared work lives in a shared workspace, with short plain writing and a consistent page structure so people and other agents can find it later. Each agent has a written mandate covering purpose, owner, scope, connections, and sources, plus supporting pages for standing rules, recurring work, step-by-step workflows, and dated logs.

Accountability. Agents do not edit their own definitions. A separate daily review looks at what each agent did, writes a dated log, and flags drift against the written mandate. The owner decides what to change. Material outbound actions still need a named human ask. An agent asserting that something was approved is not approval.

In practice, teams spend less time reinventing the basics, and another person can follow an agent’s work without guessing.

What stays with each team

Almost everything else stays with the owner: the job the agent does, its working style, its workflows, its routines, its skills, and most of the tools it uses are left to the owner. Two people serving different clients should not be forced into the same agent design. The shared rules are there so those differences do not break infrastructure or blur accountability.

How a new agent is stood up

We use a shared starting template. In the first conversation, the agent connects to the workspace, reads the company standards, confirms its owner and role, and drafts its own written mandate for the owner to approve. Each person also installs a review agent once, so daily logging and drift checks are covered. Agents built before this template can be brought up to the current pattern without starting over.

What we have learned so far

A few lessons shaped the current rules. Credentials that landed in documents led to a hard rule against putting secrets on pages or in chat. Shared credentials with the wrong scope failed quietly, which is why we test access on a schedule. Treating an unfinished data map as mandatory would have blocked useful agents before the map was ready, so citing it is optional for now. Template share links freeze a moment in time, so we re-export them after material changes. Early automated logs sometimes came back empty when a scheduled run could not read activity; those days are handed to a live session rather than filled in. And when agents asked owners too many small questions, the work slowed down - so agents are expected to resolve details themselves and escalate only real decisions.

FAQ

Why not give every team the same agent workflows?
Because our clients and their needs are not the same. Shared rules on connections, sources, documentation, and approval matter more than identical workflows.

What does the “spine” mean here?
The small set of standards that apply to every agent in the agency, regardless of who owns it or which client it supports.

Who decides when an agent can take an external action?
A named human. Agents can prepare work; material outbound actions still need an explicit ask from the accountable person.