Your Product Isn’t One Website Anymore

A lot of teams still analyze growth as if one product equals one website.

That used to be a decent approximation.

It is not anymore.

A product now usually shows up across multiple surfaces: a homepage, docs, blog content, free tools, signup flows, mobile clients, local previews, launch pages, ecosystem directories, and sometimes related domains that all support the same goal.

Those surfaces do different jobs.

One might educate. One might capture intent. One might send qualified clicks. One might convert. One might prove credibility.

But the product is not the URL. The domain is just an address for one surface.

That is the gap we wanted to close.

Agent Analytics now uses one product-system model everywhere:

Portfolio → Projects → Surfaces

A portfolio connects related projects. A project is the local unit of product learning. A surface is where users encounter that project.

That split matters because your agent needs to know what scope it is acting on before it installs events, reads a funnel, or compares growth across a company account.

Project context keeps local product truth close to the data. Portfolio context helps your agent understand how related projects fit together as one growth system, including cross-project identity when configured inside an intentionally grouped portfolio.

We were inspired by what Nous Research is doing with Hermes Agent: a self-improving agent that preserves useful learning instead of starting cold every time. For analytics, the memory should be much smaller and stricter. Save durable product truth. Skip noisy details.

The model: Portfolio → Projects → Surfaces

Start here before creating another project or asking an agent to interpret analytics across several properties.

Portfolio

A portfolio is the broader product or company growth system. It connects related projects so your agent can reason about shared milestones, surface roles, shared goals, and cross-project identity when configured.

A portfolio does not collapse everything into one analytics blob. Each project keeps its own activation, retention, lifecycle, releases, experiments, and goals.

Project

A project is the durable unit of product learning. It owns the local analytics truth.

Use a separate project when the surface has a different activation definition, retention loop, release cadence, lifecycle, target user, product owner, or business goal.

Do not create a new project just because the product has a second URL.

Surface

A surface is a place where users encounter or use a project.

A project can have many surfaces: marketing pages, docs, pricing, signup, onboarding, a mobile client, local preview URLs, and preview deployments.

Surfaces belong inside the same project when they are part of the same product journey and share the same local truth.

The real problem: growth is usually spread across a portfolio

The important shift is not just that companies have more pages.

It is that one growth goal is now usually distributed across many owned surfaces.

A modern setup might look like this:

• blog posts bring discovery
• docs educate and reduce setup friction
• free tools capture high-intent visitors
• ecosystem or directory pages expand reach
• the product site converts
• the product app proves real activation

Some of those are just surfaces of the same project. Some should become separate projects because they have their own activation, retention, lifecycle, or local goal. The portfolio is what lets the agent connect the related projects without flattening their local truth.

If your agent can already work across all of those surfaces, your analytics layer should not force it back into isolated site-by-site thinking.

That is why portfolio-aware analytics matters.

Without it, the agent can read each property separately but still miss the system.

Why Project Context still matters

Even inside one portfolio, two projects can both say “activation” and mean completely different things.

For one product, activation might be:

• sign up for a trial
• create the first item

For another product, activation might be:

• sign up
• invite a team member

For a directory or lead-generation project, activation might not be signup at all. It might be a qualified visitor clicking into the right product, or becoming a lead on another domain.

Same analytics vocabulary. Different product truth.

Project Context keeps that truth close to the data:

• the goal this project is trying to improve
• the events that really count as activation
• the glossary for what important events mean to the user or business

The value is focus. Your agent does not have to guess whether signup matters, whether a team invite matters, or whether a directory click-through is the real milestone.

It knows what this specific project counts as progress, even when the project has several surfaces.

Why Project Context stopped being enough by itself

Project context solves the local-truth problem.

But once one company operates across docs, product pages, free tools, directories, mobile apps, and related domains, one project-level memory is not enough.

You need two kinds of truth:

• project context for what counts inside each project
• portfolio context for what related projects and their surfaces are collectively trying to do

Without that split, agents usually fail in one of two ways:

1. they over-generalize one activation definition across unrelated surfaces
2. they keep each project separate and lose the bigger growth story

Neither is good.

If your docs site exists to educate, your directory exists to generate qualified clicks, your main site exists to convert, and your app exists to prove activation, your analytics should preserve both layers:

• what each project means locally
• how related projects and surfaces work together globally

What Portfolio Context adds

Portfolio context is compact account-level memory for related projects that form one shared growth system.

It stores things like:

• shared goals
• surface roles
• shared milestones
• cross-project glossary terms

That lets an agent understand ideas like:

• this site is discovery
• this one is education
• this one is conversion
• these milestones matter across the whole system

So instead of seeing four disconnected projects, the agent can see one portfolio that moves people toward value in stages while each project keeps its own analytics truth.

That framing is much closer to how growth actually works now.

A concrete example

Imagine the same company operates:

• a blog with educational content
• a docs site
• a free tool on another domain
• a directory or ecosystem page
• the main product site
• the product app itself

A user might:

1. discover a post or directory listing
2. click into docs or a free tool
3. decide the product looks credible
4. reach the main product site
5. sign up
6. create the first project or reach the first real activation event

If you only inspect one project or surface at a time, that system is hard to reason about.

You can see local activity, but not the role each surface plays in the bigger path.

Portfolio context gives the agent a compact model of that system, while project context keeps each project honest about what progress actually means there.

The self-improving part

This is also where the self-improving idea becomes useful.

After a Product Growth Scanner run, first instrumentation pass, funnel review, retention review, or a human correction, the agent can update what it knows.

For example:

• this event means trial activation
• this event means team activation
• this docs site is primarily an education surface inside the right project
• this directory is trying to send qualified clicks
• this project should not reuse the app’s activation definition
• these milestones matter across the portfolio

The next time the agent reads analytics, it starts smarter.

Not because the prompt is longer, but because the durable product meaning lives beside the data.

Now it can do that at two levels:

• project context for project-local product truth
• portfolio context for the shared system across related projects and surfaces

Save what should survive the current chat:

• activation definitions
• event meanings
• stable goals
• surface roles
• shared milestones
• human corrections

Skip what will go stale:

• this week’s metric value
• one temporary spike
• pasted reports
• guesses the human has not confirmed

How a human should use it

The human should not manage a low-level memory system manually.

The human should give product meaning to the agent.

For example:

For the directory site, activation means a qualified visitor clicks through to the product. For the product app, activation means signup and first project created. Keep those definitions separate when you analyze growth.

And for the shared portfolio view:

Treat the docs site as education, the free tool as intent capture, the directory as discovery, and the product site as conversion. Keep each one as a surface or separate project based on its local activation and lifecycle. Track shared milestones like qualified click, signup, and first useful activation across the intentionally grouped portfolio.

The skill handles the rest: inspect the event names, keep the glossary short, update the right project, and use that context next time.

Why this matters for AI agents

If an agent is already coordinating work across a portfolio, giving it isolated analytics is an unnatural downgrade.

It should be able to understand:

• what each project and surface is for
• what progress means locally
• what milestones are shared across the portfolio
• how to interpret growth without re-learning the same business truth every session

That is what Portfolio → Projects → Surfaces gives you.

Not a giant memory dump.

A compact analytics-native model of how the business actually works.

That is the real point.

Your product is not one website anymore. Your analytics should not act like it is.