Inside Jetfuel HQ: How We Built an AI Control Panel for an Agency

Jetfuel HQ is our agency's internal AI control panel. It plugs every tool our team uses (Slack, Gmail, Google Calendar, ClickUp, ad platforms, time tracking, even our own CMS) into Claude through a single connection. The result: anyone on the team can ask AI questions about real client accounts in plain English, and the answers come from live data, not a stale export.

We built it because the generic AI route was a dead end. ChatGPT and Claude.ai are powerful, but they forget everything between sessions and they cannot see your accounts. Our team was copy-pasting screenshots and CSVs into AI chats, which is slow, lossy, and a compliance headache. The bottleneck was never the AI's capability. It was the AI's access to our actual stuff.

This post is the layman's version of how it works, why it matters for marketing operations, and what we learned building it. We will keep the jargon out of the body and concentrate it in a few clearly-marked spots so engineers can find what they need.

Why we built our own control panel

A year ago, our AI workflow looked like this. Someone wanted to know how a client's Meta campaigns performed last week. They'd open Ads Manager, export the data, paste it into ChatGPT, write a prompt, wait for an answer, then close everything and start over for the next question. Repeat thirty times a day across fifteen accounts.

The numbers were right. The process was broken.

The real problem was context. Every fresh AI chat starts from zero. It doesn't know who the client is, what we tried last quarter, what our naming conventions mean, or what the Sandbox refers to. Every person on the team was re-explaining the same context over and over to the same AI.

The fix was obvious in hindsight: the AI needs to talk directly to our systems, not through a human cut-and-paste loop. So we built that.

What an agency AI control panel actually means

Strip out the jargon and this is what it is: a universal remote for our agency's tools.

Instead of opening fourteen tabs, the AI sees them all through one connection. When someone asks about a client's month-to-date spend, Claude pulls the answer from the same database the operators use. When someone asks to draft a recap email about last week's tests, it pulls the actual test data, drafts the email in Gmail, and saves it to drafts. We never send anything automatically. The human always sends.

Some real questions the team asks every day:

None of these are particularly clever questions. The clever part is that the answers come from live systems, not stale exports.

How it works (without the engineering talk)

There are a few moving pieces, and they're worth understanding because they explain why this works better than gluing AI onto a spreadsheet.

One door, many rooms

Every tool our team uses (people data, client data, ad data, content data) sits behind one connection at hq.jetfuel.agency. When someone asks Claude a question, Claude knocks on that door, gets verified, then has a specific set of rooms it can walk into based on who is asking. There is one HTTP endpoint, one auth check, one audit log. Not a different integration per tool.

The AI asks for what it needs

We don't load every tool into every conversation. That would be wasteful and confusing. Instead, the AI sees a short menu of domains at the start (clients, team, ads, research, creative, intelligence, pages, recon) and pulls in only the ones relevant to the task. Ask about ad spend, it loads the ad tools. Ask about PTO balance, it doesn't.

Each domain stays loaded for 24 hours after it gets called, so a strategist working a client all day doesn't have to re-load the same tools every conversation. The context budget stays slim and the right tools stay nearby.

How a request actually flows

A question like "what did we spend on this client yesterday" passes through about eleven discrete steps inside HQ before the answer comes back. The load-bearing ones in plain English:

• The bearer token gets checked against two authentication backends. One for interactive crew sessions (browser-based OAuth), one for automation and CI (manual personal access tokens). Either is fine, both lead to the same data layer.

• Tool visibility is filtered per user. A tool you don't have permission to use looks like it does not exist. This is intentional and prevents anyone from enumerating what they cannot access.

• The data fetch goes through the same service layer the admin UI uses, with the same authorization checks. There is exactly one path to the database, no matter whether a human clicks a button or the AI calls a tool.

• An audit row gets written before the response is returned. Even if everything else fails, that row exists.

Login is a browser click

When a new team member sets up Claude on their laptop, they don't paste any tokens or copy any secrets. They click connect, get redirected to our HQ login, click approve, and they're done. Same browser sign-in we already use for the admin panel. No engineering ticket required.

Under the hood that is OAuth with PKCE (the modern proof-of-possession variant), with dynamic client registration so we don't manage per-laptop credentials. Tokens have a sliding 90-day expiry. Every successful tool call bumps it. Active users never have to re-auth. Dormant tokens just lapse on their own.

Permissions are inherited

This is the part most people miss when they imagine AI plugged into the company database. A team strategist can pull their own time logs and their team's data. They cannot pull pay rates or PTO balances for the whole company. The AI inherits the exact same permissions that already govern the admin panel. We don't write a second set of rules for the AI, because that's where security holes get born.

Concretely, three things from the existing admin panel do all the work: role-based access (super admin, finance, default crew), per-resource policies (a pay-rate policy, a PTO-balance policy, and so on), and row-level data scoping for people data (you see yourself, your management tree, or everyone, depending on role). The AI calls the same service classes the UI calls. The rules cannot drift between the two surfaces because there is only one set of rules.

Every action is logged

Every time the AI calls a tool on someone's behalf, we record it: who asked, what tool, what input, what came back, how long it took, where the request came from, and whether it succeeded. If something goes sideways, we can answer what the AI actually did at 9:42am in five seconds.

Three things make the log usable rather than ceremonial:

• Sensitive parameters (tokens, passwords, API keys) are redacted before the row is written. Engineers cannot accidentally log a secret by forgetting to scrub it.

• Retention is 90 days for the full row, 30 days for the response body. The body gets nulled out after 30 days while the metadata stays. The log doesn't bloat the database.

• If the audit write itself fails for some reason, the original request still succeeds. We'd rather lose a log line than break someone's real work.

Why moving it off our laptops was the unlock

The first version of this lived as a 579-line Node script on each team member's laptop. It worked. It was also a nightmare to maintain.

Every time we added a new capability (say, the ability to pull Klaviyo list sizes), every laptop had to update. Pulling that off across a remote team meant Slack pings, install scripts, version-skew bugs, and at least one strategist getting blocked for two days because their setup broke. Engineering moved fast. Rollout moved slow. The team felt the lag.

We did the migration in two phases. Phase 1 in April 2026 stood up the same MCP server natively inside HQ, replacing the laptop-side Node bridge with a thin shim that just forwards requests. Phase 2 in May 2026 ported the remaining 23 tools out of the old Node codebase into native HQ adapters and deleted the laptop bundle entirely. The crew repo lost a whole subdirectory in a single commit.

The practical impact: adding a new AI capability used to take weeks of coordination. It now takes hours of code, shipped in one commit on the server, and every team member's next Claude session sees it. No reinstall, no version check, no Slack thread.

Adding a new tool is a one-file change

The whole point of the rebuild was this: an engineer should be able to add a new AI capability with a single-file commit, no team-side update required. Now they can.

The mental model is one tool per file, grouped into folders by domain. To expose a new capability, a developer drops a class into the right folder (clients, team, ads, etc.), tags it with the MCP attribute, types its parameters (the system infers the schema), and registers it in the server's tool list. That is it. The next person who opens Claude has the new tool in their menu.

Two design choices keep this tight:

• The attribute is the only way a method becomes a tool. There is no auto-routing, no "any class in this folder gets exposed." If a method does not have the tag, it does not exist as far as the AI is concerned. Exposing data is always a deliberate decision.

• Every adapter is a thin delegation to a service class. Controllers (the admin UI path) call the same service. Authorization rules live in the service, written once, inherited by both surfaces.

The 23-tool migration during Phase 2 worked because of this pattern. Each tool was a mechanical port. No special cases. No surprises in the auth layer.

What this actually unlocks for the team

A few things that were hard or impossible before, and are now normal.

Morning briefings on demand

A strategist opens Claude, asks for a summary of what happened in Slack overnight, what emails need a reply, and what is on the calendar today. Three minutes, full picture. No more starting the day with thirty open tabs.

Live spend pulls

What did we spend on Meta for this client yesterday, and how does the daily pace look against the monthly budget? The answer comes from our database, not Ads Manager UI, so it is faster and the AI can do the math.

Time and PTO self-service

Team members can ask how much PTO they have left, what hours they logged to a client last week, or submit a PTO request for next Friday. It bypasses HR back-and-forth on questions that are just data lookups.

Cross-account audits

Which of our accounts are running Performance Max without a search theme exclusion list? Used to be a 20-minute click-through job per account. Now it's a single query that returns every offender in under a minute.

Client-ready insight drafts

Pull last week's performance, compare to the prior week, draft a recap in the format that client expects, save to Gmail drafts. Human reviews and sends. The AI never sends anything on its own, but it does about 80% of the prep work.

None of this is magic. It's the result of giving AI access to the same systems the team already uses, with the same permissions, and getting out of the way.

Deliberately out of scope

There are things we explicitly chose not to do. Some of them are obvious; some of them caused real arguments inside the team before we landed on the decision. Naming them is part of how the system stays small enough to reason about.

• No external access. Staff only. Clients, partners, vendors, and contractors don't connect to HQ. If we want to share data with a client, we send the data, not the connection.

• No refresh tokens. The sliding 90-day expiry replaces them. Simpler to reason about and a much smaller attack surface.

• No scopes. One token grants whatever the user's role already allows. We considered finer-grained scopes during the OAuth design and decided against it: when permissions are already enforced at the data layer, adding a second permission system on top of OAuth just creates room for drift.

• No auto-exposing of routes. A method only becomes a tool if a developer explicitly tags it. "Just expose the database" is the fastest way to a security incident.

• No write actions that touch external parties without human sign-off. The AI can draft an email or update a record in our own admin panel, but it cannot send the email, post the campaign, or push the budget change. The human is always the last step.

What we learned building it (the 4-step pattern)

If you're an agency or in-house team thinking about plugging AI into your own stack, these are the four rules we'd write on the wall. Together they're the Internal AI Control Panel pattern.

Frequently asked questions

Next steps

Right now Jetfuel HQ does most of what we need for daily operations. The next phase is more writes (the AI proposing edits to live campaigns with human approval), better cross-channel reasoning (comparing search and social performance in a single answer), and more proactive notifications (the AI flagging an anomaly in spend before a human notices). We're rolling those out gradually, watching what breaks, tightening the guardrails as we go.

If you're a brand or agency thinking about how to actually use AI in operations (not as a writing toy, but as a system that runs alongside your team), the takeaway is this: the prompts will be cheap. The plumbing will be the moat.