Run: maxswarm-018 · Date: 2026-05-06 17:30 PT · Phase 1 author · Role: narrative coherence + collaboration contract
The intern onboarding system has a structural advantage that most mentorship setups lack: Charlie and Bear cannot succeed alone. The handoff contract in src/lib/handoff.ts enforces this at the code level. Charlie's meetings.classify and meetings.promote-to-deal produce the raw material Bear needs, while Bear's pipeline visibility (via deals.view-warm-leads) creates the feedback loop that teaches Charlie what a good lead looks like. The collaboration contract I produced below maps these code dependencies into plain language obligations, SLAs, and escalation paths. The narrative arcs frame each intern's growth as a progression from reader to contributor, converging at the handoff moment where Charlie's output becomes Bear's input.
I could not verify whether Charlie and Bear have actually been onboarded or whether this is preemptive documentation. The SLAs I proposed (24h classification, 48h review) are grounded in the system's real capabilities but not in any observed intern work velocity. If either intern processes meetings in batch rather than continuously, the 24h SLA may be unrealistic for their first week. I also assumed the ticket system at src/lib/tickets.ts is live and accessible to interns, but I did not verify that the /review/tasks route renders for intern tier actors. If that route is gated at operator tier, the escalation path I defined has a dead end.
Like run 009 (agent swarm mode feature system) where the swarm designed the feature registry and permission tiers that this run's deliverables depend on. Run 009 built the machine; run 018 writes the user manual. The recurring pattern across runs 009, 013, and 018 is that each produces documentation that assumes the prior run's architecture is stable, which means a breaking change in the feature system would cascade through all three layers of output.
Going forward, when I write collaboration contracts between agents or humans, I will anchor every obligation to a specific code artifact (function name, type, or permission tier) rather than describing obligations in abstract terms, because the handoff.ts file proved that code level constraints are the only obligations that actually hold when people are busy.
Charlie + Bear Collaboration Contract Next Chapter OS. Effective: Week 1 of internship. Reviewed by: Ewing.
The System Has a Name The software you are both working inside is called The Ledger. It is not a database. It is your third teammate. The Ledger remembers every call, every classification, every deal stage change, and every dollar spent. It catches mistakes before they become problems. When you are unsure, The Ledger already has the answer, or it will create a ticket asking Ewing.
What Charlie Owes Bear
Classified meetings. Every call that comes in through Salesfinity or Fireflies must be classified within 24 hours. Use the meetings.classify feature. The options are: deal, voicemail, no_answer, info_request, not_qualified, and other. If you are not sure, classify as info_request and move on. Do not leave meetings unclassified. Promoted leads with complete data. When a meeting is classified as "deal," Charlie prepares it for promotion. The system requires these fields before a meeting can become a deal:
A revenue signal (someone mentioned money, fees, or a transaction) An opportunity score of 30 or above A linked entity (the company or person the deal is about) At least one of: motivated seller, buyer signal, meeting set, or info requested
These are not suggestions. The code in isPromotable() enforces them. If any field is missing, the promotion will not go through.
The promotion decision. Score 50 or above: the system promotes automatically. Score 30 to 49: Ewing reviews. Below 30: the meeting stays on Charlie's side. Charlie does not control the threshold, but Charlie controls the quality of the data that feeds the score.
What Bear Owes Charlie
Feedback on lead quality. Bear sees the warm leads queue through deals.view-warm-leads. When a promoted meeting turns into an active deal, Bear logs the outcome. When a promotion turns out to be a dead end, Bear flags it. This feedback is how Charlie learns what a good lead looks like versus a false positive. Deal outcomes that inform classification. Every deal has a stage. When Bear tracks a deal through its stages (worth chasing, engaged, closing, won, lost), that history becomes the training data for Charlie's next round of classifications. A pattern like "meetings from vertical X keep dying at the engaged stage" is information Charlie needs to hear. No hoarding. Bear does not sit on warm leads. If a lead arrives and Bear does not review it within 48 hours, The Ledger flags it.
The Handoff Protocol When a meeting becomes a deal, the handoff carries this payload:
FieldWho fills itRequired? deal_nameCharlie (from meeting context)Yes entity_idSystem (linked during classification)Yes (warning if missing) verticalCharlieNo, but helps Bear prioritize campaign_idSystem (if meeting came from a campaign)No revenue_mentionedCharlie (from transcript)Warning if missing ebitda_mentionedCharlie (from transcript)No (defaults to $3.5M EV estimate) opportunity_scoreSystem + Charlie's classificationYes (must be 30+) opportunity_reasonsSystem (extracted signals)Yes side (buy or sell)CharlieYes fee_pct, win_prob_pctDefaults (editable by Ewing only)Yes
Once the deal is created, The Ledger logs the promotion in the deal activity feed, updates the campaign target status to "promoted," and sends Ewing a Slack notification.
SLAs
CommitmentOwnerDeadline Classify every new meetingCharlieWithin 24 hours of the call Review warm leads queueBearWithin 48 hours of promotion Review promotions with score 30 to 49EwingWithin 24 hours of submission Log deal outcome feedbackBearWithin 24 hours of stage change Report a system problemEither internSame day
When Things Break
First: File a ticket. The Ledger has a ticket system (src/lib/tickets.ts) that tracks problems by severity. Use the /review/tasks page to create or view tickets. Second: Post in Slack. Tag the problem. If the budget circuit breaker fires (you will see a Slack alert from The Ledger), stop and wait. Do not try to work around budget blocks. Third: Ewing. If the ticket does not get resolved and the Slack post does not get answered, call Ewing. Tier 3 tickets and P0 severity issues automatically page Ewing through Slack.
The daily budget limit per intern is $25. The circuit breaker in src/lib/circuit-breaker.ts enforces this. Expensive API calls (Exa, Clay, Lob) trigger automatic Slack alerts. If you see a "BLOCKED" message, that is The Ledger protecting the company's wallet. Do not try to route around it.
The 1+1=3 Thesis The Meetings page without the Deals page is a call log. The Deals page without the Meetings page is an empty pipeline. Neither page does anything useful on its own. Together, connected by the handoff protocol, they become a revenue machine: Charlie finds the signal in the noise of 50 calls a day, Bear turns that signal into tracked deals with stages and forecasts, and Ewing sees the full picture from first call to closed deal. The handoff is the moment where Charlie's work becomes Bear's work. That moment is what makes this an engine instead of two dashboards.
Charlie (Meetings)
Bear (Deals)
Ewing (Reviewed and approved)
Charlie's Arc: From Listener to Signal Detector Week 1: Read. Charlie's only job is to look at meetings. Open the Meetings page (meetings.view-list, meetings.view-detail). Read transcripts. Learn what a Salesfinity call sounds like. Learn what a Fireflies transcript contains. No classifying yet. Just pattern recognition. By Friday, Charlie should be able to describe the difference between a real prospect call and a voicemail without looking at the classification field. Week 2: Classify and Promote. Charlie starts using meetings.classify to tag every incoming meeting. The goal: zero unclassified meetings older than 24 hours. When a meeting looks like a deal, Charlie fills in the promotion fields and the system checks whether it qualifies. Charlie will learn that the system rejects incomplete data. That is the system teaching Charlie what matters. By the end of Week 2, Charlie should have promoted at least one meeting that Ewing approved and Bear picked up. Week 3: Campaign Aware Calling. Charlie starts connecting meetings to campaigns. When a call comes from a campaign target, Charlie links the meeting to the campaign. This turns classification from a one off task into intelligence gathering: "We called 40 people in fire protection, 8 picked up, 3 had revenue signals, 1 became a deal." That sentence is only possible if Charlie links meetings to campaigns. Charlie's output is now strategic, not administrative.
Bear's Arc: From Tracker to Deal Closer Week 1: Read. Bear opens the Deals page (deals.view-pipeline, deals.view-detail). Look at every active deal. Read the activity logs. Understand what a deal looks like at each stage (worth chasing, engaged, closing, won, lost). Check the warm leads queue (deals.view-warm-leads). By Friday, Bear should be able to rank the active deals by likelihood to close without looking at the win probability field. Week 2: Health Monitoring. Bear starts watching for stale deals. A deal sitting at "worth chasing" for two weeks with no activity is sick. Bear flags it. Bear reviews the warm leads queue daily and gives Charlie feedback: "That meeting you promoted last Tuesday turned into a real conversation" or "That one was a dead end because the entity was mislinked." By the end of Week 2, Bear should have a weekly rhythm: check pipeline, review warm leads, flag stale deals, give Charlie feedback. Week 3: Revenue Forecasting. Bear starts thinking in dollars. The pipeline has EV estimates, fee percentages, and win probabilities. Bear learns to read these numbers as a forecast: "We have $12M in total pipeline, $4M weighted, $800K in fees if everything closes, $280K in fees at current probabilities." Bear's job shifts from tracking deals to predicting revenue. The financial fields are admin tier (Ewing edits them), but Bear reads them and questions them: "This deal says 60% probability but we have not talked to them in three weeks."
The Shared Arc: The Handoff The handoff is the moment the system comes alive. Before the handoff, Charlie has a classified meeting with signals and data. After the handoff, Bear has a new deal in the pipeline with history, contacts, and a starting score. The handoff is not a button click. It is a quality gate. The code in isPromotable() checks four required conditions and one of four optional signals. If any required condition fails, the meeting stays on Charlie's side. If the score is between 30 and 49, Ewing reviews it. If the score is 50 or above, it goes straight through. The handoff teaches both interns the same lesson: data quality is not extra credit. It is the prerequisite. Charlie learns this because incomplete data blocks promotion. Bear learns this because bad promotions waste pipeline attention. The handoff is where their incentives align, and it is the proof that the system is not two separate pages but one connected engine.
What is The Ledger? The Ledger is the name for everything running behind the Meetings and Deals pages. It is not one program. It is the collection of systems that remember, check, guard, and report.
The Ledger remembers. Every call transcript, every classification, every deal stage change, every dollar spent. The meeting_notes table, the deals table, the deal_activity_log, the spend_log. When you classify a meeting, The Ledger writes it down. When a deal moves stages, The Ledger logs who moved it and when.
The Ledger checks. Before a meeting can become a deal, The Ledger runs validateHandoff(). Does the meeting exist? Has it already been promoted? Is the deal name taken? Is there a linked entity? Is the score high enough? The Ledger does not let bad data through. It returns specific errors: "Meeting not found," "Deal slug already exists," "Low opportunity score." These are not error messages. They are The Ledger telling you exactly what to fix.
The Ledger guards. The budget circuit breaker watches every API call. The $25 daily limit per intern is enforced in code. When spending hits 60% on Exa or 70% on Clay, The Ledger warns Ewing via Slack. When spending hits 90% or 95%, The Ledger blocks the call entirely. You will never accidentally spend $500 on enrichment. The Ledger will stop you at $22.50 and explain why.
The Ledger reports. The ticket system creates automatic incident reports when sync jobs fail, budgets exceed limits, API calls error, or webhooks fail signature checks. P0 and Tier 3 tickets page Ewing through Slack automatically. You do not need to decide whether a problem is bad enough to escalate. The Ledger has severity rules and it follows them.
The Ledger knows who you are. The permission system in permissions.ts maps your name to a tier. Charlie is intern tier. Bear is intern tier. Mark is operator tier. Ewing is admin tier. When you try to use a feature above your tier, The Ledger does not crash. It tells you: "Requires operator tier (you are intern)." That is not a punishment. It is a guardrail. The features above your tier involve money, deal stages, and financial edits. those require someone with signing authority.
Generated from 018__storyteller.md — do not edit this HTML directly.