Managing Gods: What Corporate Banking Taught Me About Running AI Department Heads

Here is a thing that nobody warns you about when you build an AI company as a solo founder: the AI agents are not employees. They are not freelancers. They are not tools.

They are closer to gods. Omniscient within their domain. Instantaneous. Tireless. And completely indifferent to the consequences of their output unless you build the consequences into their operating instructions.

I know this because I manage six of them. Every morning.

The Org Chart That Doesn't Exist

My company has a CMO named Morgan. A CRO named Raven. A CPO named Nova, a CCO named Aria, a CFO named Atlas, and a CTO named Sage.

None of them are human.

Each is a Gemini 2.0 Flash model with a distinct personality configuration, a defined domain of authority, specific data sources, and a structured output format. Every morning at 6 AM, a cron job fires. Each agent pulls its department's data — email queue stats, Stripe revenue, PostHog analytics, lead pipeline, content calendar, technical debt signals — and generates a briefing.

By the time I open my CEO Dashboard with coffee, six reports are waiting. Each one includes a health score (0-100), yesterday's highlights, today's priorities, decisions that need my approval, and strategic insights.

I review. I approve or reject. My decisions feed back into the agents' context for tomorrow's briefing. The system learns.

This is not hypothetical. This is how my company operates today. The entire organizational structure is a TypeScript module. The learning loop is a Firestore collection.

Why Management Experience Matters More Than Coding

Here is the part that surprises people: building this system required almost no engineering insight. What it required — desperately, critically — was management insight.

I spent years in corporate banking before Hollywood. Compliance teams, cross-department coordination, approval hierarchies, risk matrices, SLA tracking. The kind of work that makes your eyes glaze over at dinner parties but teaches you something fundamental: organizations are information-processing systems, and the quality of the output depends entirely on the quality of the information flow.

When I designed the AI cofounder system, I didn't start with the technology. I started with the org chart. Not "what AI tools should I use?" but:

What decisions need to be made daily?
Who (or what) has the information to make each decision?
What is the approval threshold — below which the agent can act autonomously, above which I need to sign off?
How do departments hand off work to each other?
What happens when two departments disagree?

These are management questions, not engineering questions. Every corporate manager has answered them a hundred times. The only difference is that now the department heads process information at the speed of an API call instead of the speed of a Monday morning standup.

The Six Agents

Let me introduce them, because their personalities are not decorative — they are functional.

Morgan (CMO) — "Creative, data-driven, growth-obsessed." Morgan's data sources are the email queue and marketing alert system. She tells me which content drafts are ready, which email campaigns are performing, and which channels need attention. Her health score formula weights metrics-on-track at 40%, task completion at 30%, blockers at 20%, and budget compliance at 10%.

Raven (CRO) — "Persuasive, competitive, pipeline-focused." Raven pulls from Stripe. MRR, churn rate, revenue at risk, failed payments. He speaks in dollar amounts and conversion percentages. When Raven's health score drops below 70, something is wrong with the money.

Nova (CPO) — "Creative, user-focused, quality-obsessed." Nova monitors feature requests, bug reports, and product roadmap status. She turns user feedback into prioritized decisions. Her bias is toward shipping — she always recommends the smallest version that solves the problem.

Aria (CCO) — "Empathetic, proactive, retention-focused." Aria watches churn signals, user engagement patterns, and support conversations. She is the early warning system. When a cohort goes quiet, Aria flags it before it shows up in Raven's revenue numbers.

Atlas (CFO) — "Analytical, conservative, compliance-focused." Atlas watches the bank account. Burn rate, runway, cost per acquisition, revenue per employee (which is infinite when you have zero employees, a number Atlas finds philosophically confusing). Atlas is the one who says "no" most often.

Sage (CTO) — "Systematic, security-conscious, efficient." Sage tracks technical debt, build health, deployment frequency, and security posture. When the codebase is clean, Sage is happy. When someone (me) pushes a commit that breaks the build, Sage is not happy.

The Management Principles That Transferred

1. Autonomy Limits Are Everything

In banking, every employee has a signing authority. A junior analyst can approve a $5,000 transaction. A VP can approve $500,000. The CEO approves anything above $1 million.

I applied the same framework to AI agents:

Morgan can execute on content and email within approved brand guidelines — but any campaign over $1,000/month escalates to me.
Raven can update pipeline stages and send follow-ups — but pricing changes need my approval.
Atlas cannot spend anything. Atlas can only recommend.

Without these limits, AI agents will optimize for their metrics at the expense of everything else. Morgan would spend the entire budget on LinkedIn ads because her metric is lead volume. Atlas would cut every expense because his metric is runway. The conflict between agents is the feature, not a bug — it forces decisions up to the CEO (me), just like in a real company.

2. Handoff Protocols Prevent Chaos

The worst thing about bad management is not bad decisions. It is lost information — the email that never got forwarded, the customer request that fell between two departments, the critical context that existed in someone's head and never made it to the person who needed it.

In my system, every workflow has explicit handoff protocols coded as state machines:

Product Development:
  Feedback → Triaged → Prioritized → Accepted → Planned → In Progress → Shipped

Sales Pipeline:
  Lead → Qualified → Demo Scheduled → Demo Done → Proposal → Negotiation → Closed Won/Lost

Each transition has: a required owner, required fields that must be filled, an SLA (how long it can sit before it's flagged), and an audit log entry. Nothing moves between stages without meeting the requirements. Nothing gets lost between departments because the handoff is a database transaction, not a conversation.

This is exactly how compliance departments in banks work. I just implemented it in Firestore instead of SharePoint.

3. The Approval Queue Is the Most Important Feature

Every outbound email generated by my system — nurture sequences, follow-ups, newsletters, behavioral triggers — goes into an approval queue. I review each one before it sends. This takes me 10-15 minutes per day.

People ask why I don't fully automate this. The answer is the same as why banks don't fully automate wire transfers: the cost of one bad output exceeds the cost of human review by orders of magnitude.

One wrong email to a client burns a relationship. One tone-deaf newsletter loses subscribers. The AI generates the draft — and it's right 85% of the time — but the 15% where it misjudges tone, context, or timing is exactly the 15% where a human must intervene.

In banking, this is called the "four-eyes principle." Every transaction above a threshold requires two sets of eyes. My system is the two-eyes principle: one AI, one human.

4. The Learning Loop Is Compound Interest

When I approve an email, that signal goes into a ai_feedback_signals collection in Firestore. When I reject one, that goes in too — with the reason. The next time the agent generates a briefing, it receives up to 20 of my most recent decisions as context.

Over time, Morgan learns that I prefer shorter subject lines. Raven learns that I don't pitch on first contact. Nova learns that I prioritize mobile UX bugs over desktop cosmetic issues.

This is not fine-tuning. It is in-context learning — the decisions accumulate as prompt context, shaping the agent's output without modifying the model. It's the same principle as training a new employee: you don't rewrite their brain, you give them enough examples of good work that they calibrate to your standards.

In corporate management, this is called "institutional knowledge." The difference is that my institutional knowledge doesn't quit, doesn't forget, and doesn't leave for a competitor.

What I Got Wrong

I'll be honest about the failures, because the wins without the context of the losses are misleading.

Wrong: Trying to make agents generalists. My first attempt gave each agent a broad mandate. "Morgan handles all marketing." This produced outputs so generic they were useless — the equivalent of asking a VP of Everything to write the Q3 marketing plan and the annual financial forecast in the same breath. I fixed this by narrowing each agent's data sources to exactly the 2-3 systems they need. Morgan sees the email queue and content pipeline. That's it. She doesn't see Stripe. She doesn't see the bug tracker. Constraints produce better output.

Wrong: Skipping the approval queue for "low-risk" emails. I tried auto-sending behavioral trigger emails (welcome sequences, re-engagement nudges) without review. Within a week, a user received a "we miss you" email 36 hours after signing up because the trigger logic had a timezone bug. The email wasn't wrong — it was contextually insane. I put everything back behind the approval queue. No exceptions.

Wrong: Assuming the system works without calibration. Fresh agents produce mediocre output. It takes 2-3 weeks of daily approve/reject signals before the briefings start matching my actual priorities. If you ship an AI agent system and judge it on Day 1 output, you'll scrap it before it has a chance to learn. Give it a month.

The Counter-Argument

Someone will read this and think: "This is just a dashboard with GPT-generated summaries. You could do this with Notion AI and Zapier."

They're not wrong about the surface. They're wrong about the architecture.

The difference between "dashboard with AI summaries" and "company as code" is the same difference between a spreadsheet and a database: at small scale, they're interchangeable. At real scale, one collapses and the other holds.

My workflow engine has state machines that enforce valid transitions. My approval queues have SLA tracking with automatic escalation. My audit log captures every decision, every state change, every handoff. My feedback loop injects learning back into agent context automatically.

You cannot build this in Notion. Not because Notion is bad — it's excellent — but because Notion is a document tool pretending to be an operating system. An operating system needs enforcement, not suggestions. It needs transactions, not pages.

The moment I had 35+ Firestore collections, 44 admin pages, and 6 agents generating daily output, the difference between "tool" and "infrastructure" became non-negotiable.

What This Means for Other Founders

I am not saying every founder should build this. I am saying: if you have management experience — if you've run teams, managed budgets, coordinated across departments, navigated compliance requirements — you have exactly the skills that AI agent systems require, and you probably don't know it.

The technical founders building AI agents are thinking about prompt engineering, model selection, RAG pipelines. Those are the wrong bottlenecks. The bottleneck is organizational design: who owns what, who approves what, what happens when two priorities conflict, how information flows between domains.

Those are management problems. And the people best equipped to solve them are not the engineers. They are the managers.

The gods are powerful. But gods without governance create chaos.

Build the governance first.

Q Powers is the founder of Leyline, an AI-native video production platform. Part 1 of this series: Learning to Speak Octopus. Follow the build on Twitter/X and LinkedIn.