A System of Intelligence for Revenue

For the last generation of enterprise software, the most important platforms were systems of record. Salesforce became the home for customers and opportunities. Outreach became the home for sequences and engagement. Gong became the home for conversations. Each became durable because it accumulated an authoritative history of an important part of the business.

AI creates the possibility for a different kind of system: one that does not just record the state of the business, but learns how the business operates.

That distinction has shaped how we have built Monaco.

A revenue organization makes thousands of decisions every week that traditional software was never designed to preserve. Why did we choose this account? Why did we contact this person now? Why did the rep use this particular angle? What did the customer actually object to? Why did the opportunity move forward? Why did it stall? Which action eventually created the meeting, the opportunity, or the win?

Most of that context disappears into email threads, meetings, individual tools, or the heads of the people who made the decision. The CRM eventually records the result: an activity happened, a stage changed, an opportunity closed. But it rarely preserves enough of the work surrounding that result to understand why it happened or make the next decision better.

An agent can be extremely capable within a single invocation and still operate inside a system with no institutional memory. At scale, it needs to know who the company has already spoken to, what has already been tried, what the buyer said months ago, and what happened the last time the organization made a similar decision. The product is therefore not just an agent that can reason, but a system that remembers the work, connects decisions to outcomes, and makes that accumulated intelligence available to every future action.

The system needs memory, not just more context

Consider something as simple as outbound.

In a controlled demo, the workflow is straightforward: find an account, identify a relevant person, retrieve some context, generate a good message, and send it. Modern models are already remarkably good at this.

Run the same workflow continuously across a real sales organization and a different class of problems appears. One rep has an active opportunity at an account while an agent starts prospecting another executive there as if the company has never heard from you. A customer operates across several domains and gets interpreted as multiple businesses. A buyer explains during a call that their real blocker is a hospital security review, but the next follow-up pitches pricing because that context did not survive the meeting. Someone completes a demo and says, “Come back after Q2 planning,” then appears in a new outbound list a few months later and receives a first-touch message from the company that already gave them the demo.

These look like different failures, but structurally they are the same. Each invocation is reconstructing the world from whatever information happens to be available when it runs.

For an agent to behave coherently over thousands of actions, the system underneath it needs durable answers to questions that are much closer to organizational memory. Who is this person? Which company do they actually belong to? What relationship already exists? What has the organization learned from that relationship? What other work is happening at this account? What actions have already been taken? Which of those actions worked?

This requires more than giving the agent more data to read. The system has to know that two email addresses belong to the same person, that three domains belong to the same company, what has already happened in the relationship, and which corrections a human made last time. That history has to survive from one run to the next.

Otherwise, the agent may get smarter while the system remains amnesiac.

I think the distinction between intelligence inside a single model invocation and intelligence accumulated by the organization over time is going to become one of the defining architecture decisions in AI software.

The architecture starts when the work happens

The most important lesson we have learned building Monaco is that organizational memory is not primarily a retrieval problem. It is a write-time problem.

Most AI products are naturally designed around reading. A question comes in, the system searches existing sources, retrieves relevant information, and gives it to a model. That works when the information you will need later has already been preserved somewhere in a durable form.

A lot of revenue work has not.

Imagine a mid-market healthcare company eventually closes a $40,000 deal. Three months earlier, a particular message variant in a sequence aimed at a specific segment generated the first meeting. If you want the system to learn from that outcome, it is not enough to ask a model after the deal closes which campaign caused the win.

When the original interaction happened, the system needed to preserve the resolved person, the company, the sequence, the message variant, the segment definition as it existed at that moment, and the time of the interaction. Months later, the contact may use a different email, the account may have been merged, your ICP may have changed, and the original campaign may no longer exist in the same form. If those relationships were never written down, there is no reliable history to reconstruct later.

Qualitative context works the same way. Suppose a prospect says during a March demo, “Let me get through Q2 planning and then let's reconnect.” That sentence can be incredibly valuable in August, but only if the system recognized it when it happened, attached it to the right person and account, and kept it as part of the relationship history.

A traditional outbound workflow may rediscover that person from a title-and-industry filter and treat them as a new lead. A system with memory understands that the company is already in a conversation. The correct action is not to introduce yourself again; it is to continue where the relationship left off.

This is why write-time capture matters so much. You cannot reliably reason later over history you never created. Without the write, there is no dependable join between the decisions the organization made and what happened afterward. Without that join, there is very little for the system to learn from. And without that learning, the 40,000th run remains structurally much closer to the first run than it should be.

Memory becomes intelligence when outcomes flow back

Recording what happened is necessary, but by itself it only gives you a better history.

The more important loop begins when the system can observe what happened after an action and use that outcome to update how it behaves the next time.

Take one of the most common moments in a sales process: a pricing objection.

A buyer says during a call that the product is too expensive. Most software can preserve that sentence. A call recorder can surface it in a summary. A CRM might attach a note to the opportunity. An agent can retrieve it before the next interaction.

But simply remembering that “price was the objection” is not intelligence.

Suppose the rep decides not to immediately discount. Instead, they reframe the conversation around migration cost: the engineering work required to keep the current stack together, the operational risk of delaying the change, and the cost of continuing to maintain several point solutions. The buyer engages differently. The opportunity advances. Eventually the deal closes.

Now the system has something much more useful than a transcript. It has a sequence of decisions and outcomes. The buyer raised a pricing objection. The rep chose a particular response. The opportunity subsequently moved. The deal eventually produced an outcome.

One example is anecdote. But when that same pattern begins appearing across dozens or hundreds of opportunities, the system can start forming judgment.

Outcomes alone aren't enough, though. Revenue is full of situations where the observed result doesn't fully explain whether the underlying decision was good. The system also needs the judgment of people who understand the domain deeply: which signals matter, which edge cases deserve different treatment, and what a great operator would have done in the same situation.

Perhaps a pricing objection from one segment genuinely predicts a budget problem, while in another segment it frequently signals that the value has not been made concrete enough. Perhaps offering a discount early improves conversion in one situation but mostly gives away margin in another. Perhaps reframing around migration cost consistently advances opportunities with a particular kind of buyer.

The next agent should therefore do more than retrieve, “This customer mentioned price.” It should be able to use the organization's accumulated experience to make a better recommendation: when buyers like this raise price at this point in the process, this response has historically produced a better outcome.

That is the transition from memory to intelligence.

The loop is not simply remember and retrieve. The system observes an event, takes an action, records what was done, sees what happened afterward, updates its judgment, and brings that learning into the next decision.

Every send, reply, meeting, stage movement, correction, and closed-won becomes another piece of evidence about how the organization should operate. The system begins distinguishing between activity and effectiveness. It can learn which combinations of signals indicate a real opportunity, which messages work for particular segments, which objections predict stalls, which actions recover them, and which corrections made by experienced operators should become default product behavior.

The models themselves will continue to improve for everyone. The accumulated operating history of an individual organization will not.

That is where the system begins to compound.

The learning loop has to span the entire revenue motion

Once outcomes matter, the architecture naturally has to extend beyond the CRM.

A large amount of the information needed to understand revenue gets created before an opportunity exists. Which accounts did we decide to pursue? Why did we choose them? What signal caused us to act now? Which person did we select? Which message earned the first reply? Which interaction produced the meeting?

The eventual deal outcome is what tells the system whether those earlier decisions were good.

That means the history has to remain intact as the account moves from discovery to outreach to meeting to opportunity to pipeline to close and renewal.

Today, that history is fragmented across point solutions. A demand-generation product knows why an account surfaced, a sales-engagement platform knows which message was sent, a call recorder knows what the buyer said, and a CRM knows the current opportunity. None naturally preserves the entire path from the original decision to the eventual outcome.

This is why Monaco was built across the revenue motion itself: find the accounts, execute the outreach, capture the conversations, manage the pipeline, close, and renew in the same underlying system. Once that continuity exists, a closed-won deal can teach the top of the funnel - not only that an account became a customer, but what originally made it interesting, which signal caused the team to engage, which message earned the response, and which actions changed the trajectory.

The system can then apply that learning back at the top: find more accounts with the same characteristics, give more weight to the signals that actually mattered, and use the messages and actions that consistently produced better outcomes.

This is the part that gets lost when AI is treated primarily as an interface layer on top of existing systems. If the agent can only read fragmented records, it can reason about the past. If the underlying system connects the entire motion, it can learn from it.

Build order becomes product strategy

This framing changes the question I would ask when evaluating an AI company.

Instead of asking only how capable the agent is, I would ask what had to exist before the agent could work reliably - and whether the system is becoming meaningfully smarter as the agents operate.

Our build order at Monaco has followed that logic. We first needed the underlying records. Then identity resolution, so one buyer remained one buyer and one company remained one company across messy data. Then a shared context layer that could consistently be read by every part of the system. Then write-time capture so important actions and decisions became durable history. Then the ability to join those actions to downstream outcomes and feed what happened back into the next decision. The increasingly autonomous agents sit on top of those layers.

That order is less satisfying at the beginning than starting with the visible agent. A sharp agent can be demonstrated quickly. Identity resolution, event architecture, attribution, caching, and feedback loops are much harder to turn into a launch video.

But the order matters because much of the eventual intelligence depends on history that cannot be manufactured later. You can add an agent after you have built the underlying system. You cannot go back in time and record the decisions, context, and outcomes you failed to capture while the organization was operating.

The pieces are also dependent on one another. Event history is unreliable when identities are unresolved. Scoring is noisy if outcomes cannot be connected back to the actions that produced them. Learning which message works for a particular segment requires enough historical executions and downstream results. Reflection without guardrails can make the system worse rather than better.

These are not independent features that can simply be copied in parallel. Each becomes more valuable because the previous layers already exist.

Production itself becomes part of the architecture. We have seen an agent flip an account list 149 times before it scored anything. We have seen a one-account fix try to recompute all 15,000 contacts until it timed out. We have seen the same contact score 90, then 50, then 70 across consecutive runs. Those are not edge cases anyone puts on a roadmap before operating the system. You discover them in production, and each one forces the underlying system to become more deterministic, efficient, and durable.

That learning matters because the product is not a collection of prompts. It is the machinery required to make thousands of decisions coherently and improve those decisions over time.

There is also a part of the learning loop that cannot come entirely from software. Some of the most valuable knowledge in revenue still lives in the judgment of its best operators: how they distinguish a serious buyer from someone politely taking a meeting, when they push versus wait, or why two accounts that look identical in structured data deserve completely different treatment.

We recently moved one of our top sales reps into EPD as a product engineer. His job is to turn that judgment into product logic, evals, cases, decision rubrics, and outcome loops. I think this is fundamental to vertical AI: the best systems will bake subject-matter expertise into the product itself, into the defaults, edge cases, and evaluations that determine how the system acts.

Production provides evidence. Outcomes tell us what happened. Subject-matter experts help define what good looks like. The system gets better by learning from all three.

A system of intelligence for revenue

The last generation of enterprise software became durable by owning the record.

I think the next generation has an opportunity to own something more valuable: the accumulated intelligence behind how the organization actually works.

For revenue, that means knowing more than the current account, opportunity, or activity. It means preserving why the organization chose the account, what it tried, what the customer said, what changed, which action was taken, what happened afterward, and what the system should do differently the next time it encounters a similar situation.

Agents are what make that intelligence operational. They can read the organization's accumulated memory before acting, execute work on its behalf, record what they did, and feed the outcome back into the same system.

We are beginning to see that loop work in production. In August, we shipped a re-engagement agent that looks for strong conversations that went cold and drafts the next move. The visible part is the draft. The harder part is everything that makes it possible: the original conversation is already attached to the right person and company, the buyer’s request has been preserved, and the system understands the relationship as a continuation rather than a new prospect. Those runs have been sustaining 20-40% response rates and turning conversations back into pipeline.

Each run inherits what the organization already knows, produces new evidence, and makes the next decision better.

That is what we are building at Monaco: a system of intelligence for revenue.