SolutionsAI token efficiency
Your agents should spend their tokens reasoning, not translating field names.
An AI agent handed raw vendor telemetry spends its context working out what the data means before it can reason about it. Normalize the Lake to open schemas and every agent you run, security triage, root cause, coding or business questions, reaches better verdicts and spends fewer tokens on each investigation.
01The problem
The parsing tax
Every token an agent spends decoding vendor field names is a token it cannot spend on the question, and on raw telemetry that tax is paid on every investigation, before the agent thinks once.
A large language model reasons over whatever arrives in its context window, and you pay for every token of it. When the evidence is raw telemetry, a surprising share of that window goes on translation. One identity provider names the person one way, another names them differently, the Windows event log uses a third field and a shorter version of the name. The same failure arrives as a word in one source, an error code in the next and a hexadecimal status in the third.
Before the agent can notice that one person failed to log in three times, it has to rebuild, inside its own context, the knowledge that these records mean the same thing. It guesses when the evidence is ambiguous, it cannot resolve identities without your directory, and it pays for the attempt every single time. That cost looks exactly like the agent working, which is why nobody sees it on the bill.
02The example
One failed login, three dialects
The same failed login from Okta, Microsoft Entra ID and Windows, with every field name exactly as each vendor documents it, is mapped across to the same OCSF Authentication fields before any agent reads it.
As each source writes it
One shape the agent reads
Okta System Log
- eventType:
- user.session.start
- outcome.result:
- FAILURE
- actor.alternateId:
- dana.garcia@example.com
Microsoft Entra ID sign-in log
- userPrincipalName:
- dana.garcia@example.com
- status.errorCode:
- 50126
- ipAddress:
- 203.0.113.24
Windows security event 4625
- TargetUserName:
- dgarcia
- Status:
- 0xC000006D
- IpAddress:
- 203.0.113.24
Your control layer
Parse, enrich and normalize, in flight
Identity resolved from your directory
OCSF Authentication, class_uid 3002
- metadata.product.name:
- Okta
- activity_id:
- 1 (Logon)
- status_id:
- 2 (Failure)
- status_code:
- FAILURE
- user.email_addr:
- dana.garcia@example.com
OCSF Authentication, class_uid 3002
- metadata.product.name:
- Microsoft Entra ID
- activity_id:
- 1 (Logon)
- status_id:
- 2 (Failure)
- status_code:
- 50126
- user.email_addr:
- dana.garcia@example.com
OCSF Authentication, class_uid 3002
- metadata.product.name:
- Windows
- activity_id:
- 1 (Logon)
- status_id:
- 2 (Failure)
- status_code:
- 0xC000006D
- user.email_addr:
- dana.garcia@example.com
Values are illustrative. Field names are as Okta, Microsoft and OCSF document them. One person, three failures, the same fields.
Raw, the agent has to decide that FAILURE, error code 50126 and status 0xC000006D mean the same thing, and guess whether a short account name and a login address are one person.
Normalized, it reads three Authentication records with the same fields: class 3002, activity Logon, status Failure, each source's own code kept, and one user resolved against your directory. It goes straight to the question: a forgotten password, or someone trying passwords?
03What changes
Quality first, cost second, portability third
Normalization does three things, in this order of importance: the same model reaches better verdicts, each investigation costs fewer tokens, and nothing has to be rewritten when a tool changes.
01
Better verdicts from the same model
The same person recognised across every source instead of split into several thin profiles. Service accounts told apart from people, so bulk transfers stop being flagged as exfiltration. Connections to several hosts read as one lateral path instead of scattered events. None of it needs a bigger model. It needs data that already agrees with itself.
02
Fewer tokens on every investigation
Shorter, consistent records that arrive already joined to their context. The agent reads less, spends fewer turns working out what a field means, and reaches a verdict sooner. Clean data is also what lets a small, inexpensive model take the routine alerts and the compliance lookups, with the large model kept for the investigations that earn it.
03
Nothing rewritten when a tool changes
A rule, a saved query or an agent prompt written against the schema works for every source mapped to it. Add an identity provider, swap a SIEM, or live through a vendor renaming a field, and you change one mapping in the pipeline instead of rewriting your detection content.
A vendor-published benchmark by Gruve.ai (February 2026) ran one agent with one prompt over the same Zscaler logs, raw and then normalized to OCSF. Normalized, it resolved one user that the raw run had split into three, suppressed a service account the raw run had flagged as exfiltration, and linked a lateral move the raw run had read as unrelated events. It is a single dataset with qualitative results, which is why we cite what it found and not a number.
04Every agent
Every agent you run reads the same Lake
Security triage, root cause analysis, coding agents and business questions all read the normalized Lake, so the foundation is built once and every agent after it starts on clean ground.
Security triage
Works every SIEM alert on the Lake and your runbooks. Normalized identity and actor type are what separate an attack from a forgotten password.
Root cause analysis
Follows an application alert into the service, the host and the trace underneath it, joined on the same keys the security events carry.
Coding agents
Read your pipelines, rules and dashboards as code. One schema means one field name to change, not one per vendor.
Business questions
Compliance, audit and cost questions in plain English, answered by a small model against records that already mean the same thing.
05The standards
Not one schema: two open standards that join
Security events land in OCSF and metrics, logs and traces land in OpenTelemetry semantic conventions, and the two meet on the host, the service, the user and the trace ID.
OCSF for security events
The Open Cybersecurity Schema Framework defines classes such as Authentication, Network Activity and Process Activity. A Linux Foundation project since 19 November 2024, and the format Amazon Security Lake stores.
OpenTelemetry for everything else
OpenTelemetry semantic conventions name hosts, services, requests and databases. Since the April 2023 convergence announcement they are the successor to the Elastic Common Schema.
Joined on shared keys
Host, service, user and trace ID. The join is what lets one agent follow a suspicious login to the service that account runs, the host underneath it and the request that failed.
06The work
How we build it
Normalization happens in your control layer, in flight, as code in your repositories, before anything lands in the Lake, so every consumer reads data that already means something.
- Parse every source in your control layer, in flight, before anything lands.
- Enrich each event with what the source never knew: the directory identity behind a short account name, the team that owns the host, whether an address is internal.
- Map security events to OCSF and metrics, logs and traces to OpenTelemetry semantic conventions, joined on host, service, user and trace ID.
- Keep every mapping as code in your repositories, reviewed and tested, so a vendor renaming a field fails a test instead of silently breaking a detection.
- Write the result to the Lake you own, partitioned for retrieval, so your SIEM, your analysts and every agent read the same clean record.
The mapping is judgment, not a lookup table: which event class a log belongs to, which enrichment matters for which question, how identities resolve across systems never designed to agree. It is the first thing the foundation builds, and the reason the agents that follow are worth running.
07Questions
What teams ask about this
The three questions we hear most about normalization and what it does to an AI bill.
How much will normalization cut our AI bill?
We do not quote a percentage, and we would be wary of anyone who does without showing their measurement. The size of the saving depends on how many sources you run, how inconsistent they are, and how much of each record your agents read. What is certain is the direction: shorter, consistent records and fewer turns per investigation, and a small model able to take the routine work. The architecture review is where we look at your own sources and agents.
Why not let the model work out the field names itself?
Because it pays for that work on every call, it guesses when the evidence is ambiguous, and it cannot resolve identities it has no directory for. A mapping done once in the pipeline is paid once, reviewed once, tested, and shared by every consumer, the SIEM and the analysts included.
Do we have to move off our SIEM to do this?
No. The control layer sits in front of your SIEM and your APM, never in place of them. Your SIEM keeps receiving what it needs, now cleaner, and the full normalized record lands in the Lake you own for your agents to read.
08Read more
The journal pieces behind this
The longer read, with the sources on the page.
See your architecture drawn, with the costs, before you spend anything.
Our lead architects draw your SIEM feed from your diagrams: where the cost sits, what step one would change, and where it would not pay. If it pays, the next step is a two-week proof on your noisiest source.
Free. No system access. No obligation. You keep the drawing.
What you get
- Your architecture today, drawn
- The waste map
- Costs before and after, with estimates
- Your target architecture
- Options for your business problem
What it costsNothing