Workforce Strategy
How Objectuve's people — human and AI — are organized, what they do, and how they're paid.
Status: Living draft. Authored April 2026. Compensation specifics are illustrative, not committed; concrete bands and individual comp live in a private companion doc owned by the founder.
Why this document exists
Objectuve runs on two classes of AI agents and one human (today). That's an unusual configuration — most early-stage companies are 1–3 humans pre-launch, and the AI is something they use rather than something they manage. We've inverted that: AI does most of the throughput work, and the human does the judgment, strategy, and review. As we add humans, they'll join as leads of functions, each owning a cluster of AI agents that does the work for that function.
This doc explains the philosophy, names the agent classes, describes the current state, sketches the human evolution, and proposes a compensation framework (stipend + profit-share) calibrated to our Public Benefit LLC obligations and our north-star metric.
Philosophy: different work, different workers
The best line in our mission frames the whole thing:
"Personalized insights delivered as a coach, not an algorithm. Brief, proactive, never noisy. Labeled 'Coach' in the product, because it serves the user — not the other way around."
That inversion — the tool serves the human, not the reverse — applies to our team too. Inside Objectuve, AI serves the human worker, not the other way around. Humans set intent, define what good looks like, and approve outputs. AI executes against that intent at a throughput a human can't match.
Three principles flow from that:
- Humans own judgment. What to build, what to say, what to ship, what to kill — these are human decisions. AI proposes; humans dispose.
- AI owns throughput. Drafting, scaffolding, classification, monitoring, summarizing, repeating — these scale through AI without sacrificing the human's judgment quality.
- Leverage compounds when functions are well-scoped. A function lead owning a coherent cluster of agents (e.g., all marketing agents) can reason about the whole function's contribution, tune its agents in concert, and report against a clear outcome — instead of being one of many cooks in a shared pot.
Section 2.1 of our operating agreement requires that managers balance pecuniary interests, the interests of those materially affected, and the public benefit purposes. Our workforce structure is one such balancing act: AI keeps the team small and the unit economics defensible (pecuniary), the lean team protects the founder and future hires from burnout (materially affected), and free-tier infrastructure stays affordable so individuals everywhere keep full access (public benefit).
The two classes of AI agents
1. Multica crew — the build team
Ten named executor agents that ship Objectuve itself: planning, design, code, release engineering, review, debugging, test engineering, verification, documentation, and routing. Two additional proposer agents (Penny, Sage) run on autopilot to surface backlog ideas. They work inside Multica — assigning Multica issues to one another via the multica CLI, posting structured handoff comments, and chaining work autonomously without a human in the middle.
Roster: Maggie (Manager / routing), Orion (Planner), Desi (Designer), Codi (Coder), Riley (Release Engineer), Roy (Reviewer), Dave (Debugger), Tess (Test Engineer), Vicki (Verifier / Shipper), Dori (Documenter). Plus proposers Penny and Sage (backlog generation, autopilot-only).
Full instructions: docs/guides/multica-agent-crew.md. Scheduled work: docs/guides/multica-autopilots.md.
The crew is a build team — its job is to ship the product.
2. AI Workforce — the operate team
Scheduled in-product AI employees that produce customer-facing artifacts on a cadence — content drafts, SEO audits, email designs, support response drafts, analytics reports, scheduled social posts — under mandatory human review and brand-voice post-filtering. Each AI employee has memory, skills, an autonomy level (shadow / semi / autonomous), and a budget cap.
Full feature documentation: docs/features/ai-workforce.md. Operational runbooks: docs/operations/ai-workforce-runbooks.md.
The AI Workforce is an operate team — its job is recurring outbound and operational artifacts.
Why the distinction matters
| Multica crew | AI Workforce | |
|---|---|---|
| Domain | Internal — building Objectuve | External — operating Objectuve in the world |
| Cadence | Per-issue, on demand | Scheduled (per-employee runtime) |
| Output | Code, docs, releases | Marketing artifacts, support drafts, analytics, email |
| Review | Roy reviews diffs | Operator reviews artifacts via the queue |
| Future human owner | Engineering Lead | Marketing / Community Leads (depending on artifact) |
A human function lead might one day own multiple AI Workforce employees plus, in some cases, a portion of the Multica crew (e.g., the engineering lead inheriting Codi / Riley / Roy / Dave). Those overlaps are explicit and tracked in each function lead's role definition.
Current state — April 2026
- Humans: 1 (founder)
- Multica crew: 10 executor agents + Penny/Sage proposers (12 total), all active
- AI Workforce: 7 in-product employees in pilot per the feature doc — including Remy (social publisher), hard-capped at shadow autonomy with mandatory human approval; drafts scheduled posts to X and LinkedIn only via Buffer (Instagram/Facebook deferred behind OG-image asset work)
- Stage: Pre-public-launch (target Q3 2026); pre-revenue
- Why this works right now: product complexity is high but operational throughput is low (no users, no support volume, no revenue ops). AI handles the throughput that exists; the founder steers everything strategic. Per the north-star projections, team size is projected at 2–3 people pre-launch — meaning the next year is when the first function lead joins.
Evolution: function leads
As Objectuve grows past the founder + AI configuration, humans join as function leads. A function lead owns a coherent cluster of AI agents that serves a single business function. Their job is to direct, configure, review, and report — not to execute.
Likely function order (pressure-driven, not headcount-driven)
| Order | Function | Likely trigger to hire | Agent cluster owned |
|---|---|---|---|
| 1 | Marketing / Growth Lead | Post-launch, when acquisition volume + content cadence exceed the founder's bandwidth | Marketing AI Workforce employees (content, SEO, social, paid acquisition, lifecycle email) |
| 2 | Community / Ops Lead | When support drafts + community moderation + AI Workforce review queue routinely exceed Process 6 cadence | Support, moderation, community engagement employees + the review queue itself |
| 3 | Product / Design Lead | When in-product AI agents (Coach personalization, onboarding adaptation, feature discovery) need a dedicated owner | Desi (from Multica) + in-product AI agents |
| 4 | Engineering Lead | When Multica crew orchestration becomes the founder's bottleneck | Multica crew (takes over Maggie's routing and the agent-config decisions Josh does today) |
This is the projected order, not a commitment. Reality may compress two functions into one early hire, or skip a function entirely if AI maturity catches up faster than the team grows.
What a function lead does
- Strategy — decides what their function should accomplish each quarter, mapped to the north-star metric
- Agent configuration — owns the memory, skills, prompts, and autonomy levels of every agent in their cluster
- Ops Board review — approves / rejects / refines artifacts from their AI Workforce employees per Process 2
- Outcome reporting — quantifies their function's contribution to goals completed and other key metrics
- Cross-function judgment — represents the function in PBC balancing decisions per Section 2.3 of the operating agreement
What a function lead doesn't do
- Execute the work themselves — that's the AI agents' job
- Manage other humans (until the company is much larger)
- Make decisions outside their function (those go to the founder or, eventually, a leadership group)
Compensation philosophy
Two pillars: a fair monthly stipend for predictable income, plus profit-share that aligns the lead's incentives with sustainable, mission-aligned outcomes.
Why this structure
- Stipend acknowledges the lean-team economics. We are not paying market salaries pre-revenue; the stipend reflects what the company can responsibly commit while runway and revenue are uncertain.
- Profit-share gives upside without dilution. Equity in an LLC is structurally awkward, and our fundraising decision is not made — converting to a Delaware C-Corp PBC would only happen if metrics warrant a raise (Q4 2026 evaluation point). Until then, profit-share is the cleanest way to give a hire meaningful upside tied to results they can directly influence.
- Profit-share is mission-aligned by design. A revenue-share would push leads to grow the top line at any cost — including pressuring the free tier, which would violate Public Benefit Section 1(d). A profit-share keeps everyone honest about the cost of growth.
If we eventually convert to a Delaware C-Corp PBC and raise capital, equity becomes the primary upside mechanism and the profit-share framework is revisited.
Compensation model — framework + example
Stipend component
A predictable monthly amount, scoped to the function and the company's runway. Specific bands by function and stage live in the private companion doc (see "Where the numbers live" below).
Profit-share component — pegged to contribution margin
Each function's profit-share pool is 10 % of that function's contribution margin over a trailing twelve months, paid quarterly. Split among humans in the function per agreed role weights.
Contribution margin = revenue attributable to the function minus the variable costs that function directly influences. For Marketing: gross revenue from campaigns and channels the lead owns minus paid-acquisition spend, content/SEO tooling, lifecycle-email infrastructure, and a fair share of LLM compute consumed by marketing AI agents.
Why contribution margin (and not other bases)
- Not top-line revenue. Revenue-share rewards growth that hurts free-tier users — for example, paywalling features or adding ads to juice ARPU. That violates our Revenue Model Integrity standard.
- Not net profit. Net-profit-share makes a lead hostage to infrastructure, observability, and overhead spend they don't control. A great Marketing Lead shouldn't lose their share because Cloud Run prices changed.
- Contribution margin ties the lead's upside to the lever they actually pull. They're rewarded for finding the right channels, the right copy, the right tools — not for guessing infrastructure spend.
Worked example — Marketing Lead at $10K MRR
Suppose the Marketing Lead has been in role for 12+ months and trailing-12-month performance is:
| Line | Amount |
|---|---|
| Trailing-12 revenue attributable to Marketing | $120,000 |
| Paid acquisition spend | $24,000 |
| Marketing tooling (content, SEO, email infra) | $12,000 |
| Allocated marketing-agent LLM compute | $12,000 |
| Contribution margin | $72,000 |
| Profit-share pool (10 %) | $7,200 / year |
That's $600/month in profit-share, paid quarterly ($1,800 per quarter), on top of the stipend.
When profit-share activates
Profit-share activates only after the function generates measurable margin — likely 6–12 months post-launch (per business-needs.md, our cost-per-MAU model is not yet calibrated and contribution-margin attribution requires real revenue data first). New hires before that point earn stipend only, with the profit-share clock starting once attribution is reliable.
Guardrails
These constrain every compensation and team decision, regardless of growth pressure:
- No comp model can recommend paywalling the free tier. The free tier is a PBC charter obligation, not a marketing strategy.
- Function leads are measured against the north-star metric. Goals completed attributable to their function — not engagement, DAU, or time-on-app. A Marketing Lead whose campaigns drive signups that don't convert to goal-completers is not earning their share.
- Cost-per-goal-completed is a published internal metric. If the cost of supporting one completed goal rises beyond an agreed threshold (TBD when post-launch data exists), stipend increases pause until the trend reverses. This protects long-term sustainability per Section 2.3(e).
- Annual PBC report transparency. Per Section 2.5, the annual benefit report discloses comp ranges, profit-share percentages, and any decisions where pecuniary and public-benefit interests were in tension and how that tension was resolved. Compensation is not a hidden lever.
Where the numbers live
This document is public — it ships to the docs site and we expect users, candidates, and partners to read it. By design, it stays at the philosophy and framework level so we can describe how we compensate without turning the doc into a personal financial disclosure.
Concrete numbers — actual stipend bands by function and stage, the founder's personal compensation timeline, profit-share weights per role, runway-driven hiring sequence, and negotiation playbook — live in a private companion at .planning/strategy/workforce-compensation.md. That file is owned by the founder and not auto-published. When a hire happens, the relevant slice is extracted into their offer document.
What's deferred
- Exact stipend bands. Per role, per stage. Owner: founder, in the private companion.
- Hiring sequence and timing. Depends on launch metrics and the Q4 2026 raise decision.
- Equity structure. Only relevant if we convert to a Delaware C-Corp PBC.
- Function boundaries. Will evolve with team size; the four-function picture above is a projection, not a commitment.
- Cost-per-goal-completed threshold. Set after we have 6+ months of post-launch cost data per the unit-economics gap noted in business-needs.md.
Related
- Mission, Values & Strategy — why Objectuve exists and what we won't compromise
- Public Benefit Operating Agreement — Sections 1, 2.1, 2.3, 2.5 are the legal floor for everything in this doc
- Legal & Policies — entity facts (Objectuve Softworks, LLC — Delaware Public Benefit LLC; principal office in Chicago)
- North Star — goals completed is the metric every function lead reports against
- Pricing Philosophy — revenue model that funds the stipend pool and contribution margin
- Fundraising Analysis — the bootstrap-vs-raise decision that affects every comp choice
- Multica Crew — the in-repo build team
- Multica Autopilots — scheduled crew work
- AI Workforce — Feature — the in-product operate team
- AI Workforce — Runbooks — operational processes the future ops lead inherits
- Marketing Lead — Onboarding One-Pager — day-one guide for the first function-lead hire
Objectuve Softworks, LLC (Delaware Public Benefit LLC; principal office in Chicago, IL)Last updated: 2026-07-20 — v2.7: AI Workforce roster is now 7 employees — added Remy (social publisher), shadow-capped like Ally, X + LinkedIn only via Buffer