Which "last week" did your AI use?

Ask two analysts at the same company a simple question, "how did checkout do last week," and you can get two different answers. One counts a checkout as complete at the payment confirmation. The other counts it when the order actually clears fraud review. One reads "last week" as the last seven days, the other as Sunday through Saturday. Both are defensible. Both have been half true for years. Everyone works around it.

Now add a third analyst to the team. This one's fast, tireless, and reads every row of data in seconds. It's also brand new, has never seen your internal definitions, and hasn't met anyone who could explain them. Ask it how your checkout did last week and it'll give you a number, confidently, in plain language, in a few seconds.

Which definition did it use?

Most AI analyst demos skip that question. It's often the first one your CFO asks. A generic agent will always answer. Fluently. But fluency is exactly what makes a wrong answer dangerous, because it doesn't look wrong. What matters is whether the analysis speaks your business's language.

A generic answer is the wrong answer in disguise.

Every company runs on its own logic. Your definition of an active user, the segments you exclude, what "last week" means in your reporting, the investigation your best analyst runs on instinct when conversion dips: none of that lives in the raw data. It lives in your team's heads, in a half-updated wiki, and in the tribal memory of the three people who've been there longest.

A generic AI tool doesn't know any of it. It can read your data flawlessly and still answer the wrong question, because it's using a reasonable-sounding definition that happens not to be yours, or running a textbook investigation instead of the one your business has learned to trust. That's the difference between a nicer way to ask for metrics and a true analyst. It's also the difference between an AI that knows the data and one that knows your business. Felix AI is built to close that gap, and it closes it by learning how your team actually works: your definitions and your conventions.

You don't have to set any of this up before Felix is useful. It works on your data from day one, and it gets sharper with every definition and rule you teach it.

That customization runs on two capabilities that work together. Here's what each one does.

Skills: the business context Felix reasons with.

A Skill is a layer of your business's knowledge that Felix pulls in when it's relevant and uses to reason with.

Say Felix spots an error: a spike in failed form submissions, an API call failing, a burst of rage clicks on a page that used to convert. Diagnosing what's actually wrong is the kind of thing your most experienced people do on instinct. They know which signals matter and which are noise, what a particular error usually means in your app, where to look first, and what "normal" looks like so they can tell a real problem from a blip. Little of that lives in the raw data. A Skill captures it, the diagnostic knowledge your team leans on when something breaks, so the moment Felix finds an error it's working from how your business actually troubleshoots instead of starting from zero.

You could write that as a fixed checklist, step one, step two, step three. But a rigid sequence is the wrong tool for a model that can think, and it throws away the thing that makes it worth having. Your best analyst doesn't diagnose every error the same way. They form a hypothesis, test it, drop it when the evidence says otherwise, and follows the trail. Felix works like that too. So a Skill doesn't lock it into a sequence. It hands over the knowledge, what the signals mean, where to look, what counts as normal here, and lets Felix reason through the specific error in front of it, trying approaches and correcting course the way your best person would. The more it understands about your business, the sharper that reasoning gets.

A Skill can hold a single area of knowledge like that, or a whole approach to a recurring question. Take campaign performance as an example. Your team's approach might be to start with which campaigns drove the most activity, by event count and sessions, then check whether that activity turned into purchases, pulling conversions, conversion rate, and revenue by campaign. For the best-converting campaigns, look at what those users actually did on the way to buying, so you can repeat it. For the worst, hunt for the friction, an error, a dead end, a confusing step, blocking conversion before the campaign gets a fair shot. A Skill called "Campaign Performance Analysis" hands Felix that approach as context it reasons from and adapts to whatever's actually being asked, rather than a checklist it runs blind.

Skills carry more than framing. A Skill can also hold the queries Felix runs, already validated against your data, so it pulls the exact numbers your team trusts instead of rebuilding them from scratch each time. The knowledge tells Felix how to think about the question, and the saved queries make sure the figures underneath are the right ones.

Either way, the payoff is the same. The knowledge that used to live in one person's head becomes something Felix reasons with, the same way, for everyone who asks. You teach it once, and it persists, so every answer is grounded in the same understanding of how your business actually works. And teaching Felix rarely means sitting down to write documentation. More often you run the analysis in a chat, get it right, and save that session as a Skill on the spot. The work you already did becomes the thing everyone reuses.

Directives: your rules, enforced in every session.

Skills give Felix the context behind your business's concepts. Directives are the standing rules Felix follows in every agent session, no matter what's being asked. The quick test for which to reach for: if it's knowledge Felix should understand, make it a Skill. If it's a standing constraint on how Felix should behave, make it a Directive.

Most of them read like a simple instruction you'd give a new hire who keeps getting one detail wrong. "Whenever I ask for 'last week,' analyze Sunday through Saturday." "If someone mentions Project Alcove, they mean all the changes we're making to our landing pages." "Always check and include the variation range, variance, min-max, or standard deviation, when analyzing metrics or baseline comparisons." They're small, and that's the point. Directives catch the conventions and vocabulary that are obvious to your team and invisible to a generic model, and they apply them everywhere, automatically, so you don't have to restate them in every prompt.

This is the layer that fixes the "it answered confidently and got it subtly wrong" problem. The wrongness usually isn't in the math. It's in an assumption, a date range, a term that means something specific at your company and something generic everywhere else. Directives put those assumptions under your control instead of leaving them to the model's best guess, and because they're managed in one place, scoped by workspace and reviewable, your whole team inherits the same rules rather than each person discovering the quirks on their own.

You don't have to think these up yourself. Felix proposes Skills and Directives as it watches you work, noticing a definition you keep restating or a rule you apply by hand, and offers to save it. Those proposals go to review before they take effect, so nothing gets applied in your name until someone approves it. That review step is the point: it's how the set stays intentional instead of filling up with rules nobody remembers creating.

There's a catch worth saying plainly. Someone has to own your Skills and Directives, and they need upkeep when definitions change. A Directive that's wrong gets applied everywhere just as consistently as one that's right. And before you can write one, your team has to agree on which definition wins. That conversation can be the most useful part of the whole exercise.

An enterprise platform needs to be able to support a definition like "engaged users" across multiple teams, since marketing counts engagement as opens and clicks, while the product team means time in the app or features used, and the CX team means someone who's interacting meaningfully with multiple page hits. Quantum Metric workspaces allow each team to have their own directives and skills, allowing Felix to not just know your business, but each individual department as well.

Together, they make Felix yours.

Skills and Directives work as a set. Skills give Felix your business's concepts, the context behind them, and the queries to answer them. Directives carry your rules and conventions into every session. Each one takes something that used to live in someone's head and writes it down where Felix can use it. Together they help Felix start answering in your team's terms.

This is also where experience context comes in. Experience context tells Felix what your customers did. Skills and Directives tell it what that means at your company. Felix needs both to answer the way your best analyst would.

The point is that Felix starts reasoning in service of what your team is actually trying to do. An analytics tool that knows your definitions and your rules doesn't just report that conversion moved. It weighs that move the way your team would, flags what's worth attention given your priorities, and frames the answer in terms you can act on. Felix is built to get better at this over time, because it can be taught: the more of your business it learns, the more it answers the way you would.

This is the line between fluent and correct.

Any modern model can produce a fluent answer. That's table stakes now. The hard problem is producing the answer your business would actually stand behind, and that depends entirely on whether the agent is operating from your definitions and your rules or from generic assumptions it inferred on the fly.

An agent without that context will hand you a number that looks right, use a definition that isn't yours, and send you into a meeting to defend a figure that was never measuring what you thought. That's worse than no answer, because it costs you the meeting and your credibility before anyone notices.

Customizing Felix to your business is how you close that gap, and because Felix keeps its reasoning auditable, you can see which definitions and rules it used to reach an answer, and check the work yourself.

How to tell if an agent actually knows your business.

If you're evaluating agentic analytics, this is the question that cuts through the surface. Ask the vendor how the agent learns your specific definitions, and what happens the first time your version of a metric, or your meaning of "last week," differs from the obvious one. Then ask whether that knowledge persists, or whether someone has to re-explain it in every session.

If the answer is that the agent is "smart enough to figure it out," be skeptical. Figuring it out means guessing, and guessing about your definitions is exactly the failure mode that produces confident, plausible, but wrong answers.

What you want to hear is that you can encode your definitions and your standing rules once, that teaching a new one can be as simple as saving a chat that already worked rather than authoring documentation nobody maintains, that every answer inherits them, and that you can see the reasoning behind any result. That's the difference I'd look for.

The part that compounds.

The best reason to teach an agent your business is that the investment accrues. Every Skill and Directive you define is institutional knowledge that stops living only in one person's head and starts being applied every time someone asks. When your best analyst leaves, their definitions don't leave with them. When a new team member asks a question, they get the same rigor your most experienced person would've applied. The agent gets more useful the more of your business it learns.

This is the piece that turns Felix from a capable AI tool into your team's AI analyst. An agent has to reason over raw experience data rather than just fetch what someone pre-built. It has to watch continuously so the questions nobody thought to ask still get answered. And it has to know your business well enough to answer the way you would.

The data tells the agent what happened. Your definitions and your rules are what let it tell you what happened here, at your company, in terms you can act on. That's the difference between an analyst you can trust and a very fast stranger with an opinion.

See what changes when the agent answering your questions already knows how your business defines the answer: explore Felix AI Agentic.