Playbook
How to run a SaaS portfolio with AI agents
A practical playbook for setting up 90-day cycles, assigning domain agents to your products, writing goals agents can work from, and running the decision review process without losing your strategic voice.
Setting up your first agent assignment
Start by connecting AgentCompany to one product in your DVGProOS portfolio. Pick the product where you have the clearest goals and the most relevant signals — metrics, customer feedback, or recent decisions that agents can use as context. Connecting a product with vague objectives and no signal inputs will produce generic proposals regardless of how good the agents are.
Once connected, assign domain agents to the areas where you want proposals. You do not need to activate all four domains immediately. Many founders start with growth and product, then add ops and finance once they understand what useful proposals look like in their context. Each agent you activate needs a domain scope: the boundaries of what it is responsible for within this product and what it is explicitly not expected to address.
After assignment, set the cycle start date. Agents will not produce proposals until a cycle is open and goals are defined. The cycle creates the container — everything the agent produces in the next 90 days will be scoped to the goals you set at the opening.
What makes a good 90-day goal for an AI agent
The most common mistake in setting agent goals is writing objectives that are too broad to produce actionable proposals. "Grow revenue" is not a goal an agent can work from. "Increase trial-to-paid conversion from 18% to 25% by reducing friction in the onboarding sequence" is a goal an agent can produce specific proposals against.
Three criteria determine whether a goal will produce useful proposals. First, specificity: the goal should name the metric, the current state, and the target state. Second, measurability: you should be able to verify at cycle close whether the outcome was achieved. Third, bounded scope: the goal should be achievable within the agent's domain without requiring decisions from other domains to unlock it.
Goals that span multiple domains tend to produce proposals that are either too vague or that require cross-domain coordination the agent cannot supply. Break those goals into domain-specific sub-goals and assign each to the relevant agent. The coordination happens at the founder level through the decision inbox, not inside the agents.
Reviewing proposals without losing your strategic voice
The decision inbox is where founders stay strategic rather than operational. When a proposal arrives, resist the instinct to edit it into a task list. Instead, evaluate it against the goal it maps to: does the agent's rationale reflect accurate context? Are the recommended actions within your risk tolerance? Do the expected outcomes represent a meaningful step toward the goal?
If the answer to all three is yes, approve the proposal and log any execution notes. If the rationale is sound but one or two actions are not, approve the proposal partially and annotate which actions you are rejecting and why. The annotation becomes the agent's context for the next proposal, so specificity here pays compound dividends — a clear "we do not have the ops capacity for this channel right now" prevents the same recommendation from reappearing in the next cycle.
At cycle close, record the outcome against each approved proposal. Even a brief note — "conversion improved from 18% to 22%, short of the 25% target, primary blocker was checkout friction not onboarding" — gives the next cycle's goal-setting a grounded starting point. Over time, this outcome log becomes the most valuable artifact in your AgentCompany instance: a record of what your agents proposed, what you decided, and what actually happened.