Pre-training and post‑training agents

Every frontier model is built in two phases. Pre-training optimizes one simple objective, predicting the next token across a huge corpus, and getting good at it forces the model to absorb broad knowledge of the world. Post-training shapes that knowledge for specific jobs with supervised examples and reinforcement learning. Because the expensive learning happens once, one base model can be specialized many times.

We think agents that work inside an enterprise need the same split. In pre-training, one or more agents learn a company's environment the way a new staff engineer does in their first year: which records in the cloud, the scanners and the CMDB describe the same asset, which team owns each service and answers its pages, how identities, networks and data connect, where the crown jewels are, and which sources disagree or have gaps. They do this continuously, each run starting from the best version so far and going deeper where the picture is still thin, and they write everything down as a broad, cited model that any later task can start from. In post-training, a second set of agents starts from that model and goes deep on one hard problem at a time, such as finding attack paths that hold up under verification or tracing container vulnerabilities to the team that can fix them. They work through each problem on their own, fit the result to how each customer works, and check every output before it is published. We build these agents for security teams, and that is the setting we use throughout: thousands of assets spread across cloud accounts, a dozen tools that each see part of them and rarely agree, and a backlog of vulnerability findings no team can work through by hand. This is an analogy, and no model weights change. What we refine is the knowledge the models read, drawn from the hundreds of systems an enterprise runs on. Most agents today skip pre-training. An agent asked to fix a vulnerability finding makes a single pass through those systems and learns just enough: that four records in four tools are the same machine, who probably owns it and whether it is internet-reachable. When the run ends, it loses most of that.

A security engineer doesn't understand a company after one look either. The first weeks go to names and inventories. By month three they know which CMDB fields are wrong and which scanner misses the Kubernetes clusters. By year two they know which internal service quietly handles payment data, which team answers a page about it, and which assumptions broke in the last migration. None of it is in any model's weights. It is private to one company, spread across cloud accounts, scanners, a partly correct CMDB and years of Slack and Jira, and it changes every week.

At Cogent we have built the Context Engine, a system that learns a company this way, run after run, and builds a security world model of it. Our main pre-training agent today is an environment mapping agent. Every few hours it works through every connected system (about fifty connectors) and updates a cited world model. By security world model we mean a working picture of what exists in the environment and how it fits together: which records describe the same thing, who owns it, how it connects to everything else, and what is missing or contradictory. Post-training agents build on it. The recipe isn't specific to security, but security is where it is easiest to check, which is a large part of why it works there.

Figure 1. Pre-training builds and refines the world model on a schedule. Post-training agents use it for specific deliverables, and verified results flow back into it. Dashed lines are planned.

The LLM training recipe, translated

Pre-training agents: learning the environment

We hold pre-training agents to what a staff security engineer would know after years at the company, across architecture, identity, ownership, exposure, topology and business importance. The environment mapping agent, our main one today, reads whatever the customer has connected, decides where to look, follows contradictions, and records what it learns so other agents can use and check it.

The world model has two layers. The first is an agent wiki of markdown pages, one concept per page. hot/ pages hold the current picture, which a staff engineer should be able to absorb quickly, and cold/ pages hold the evidence, rationale, contradictions and open questions behind it. Each page starts with frontmatter from a small subset of Google's Open Knowledge Format: a type, title, one-line description, tags, references into the graph and an optional stale_after date. Agents write only those fields. After each run, a script regenerates the wiki's index from that frontmatter, so the index always matches the pages. Agents read the index before opening any page. The shape will be familiar from Karpathy's notes on LLM knowledge bases or Devin's DeepWiki. Because the pages are written for people too, the wiki doubles as one a security team can browse.

Figure 2. Inside the pre-training store. Pages link down into the graph, and both cite source records. Runs promote stable findings into hot/, and each run's scratchpad keeps its trace and a note for the next. Compaction merges, splits and retires pages.

The second layer is a knowledge graph, because files and grep handle identity and relationships poorly, and identity is most of the problem in security. Cloud servers are often easy, since AWS, Wiz and CrowdStrike all carry the instance ID. The hard cases are re-imaged machines that come back with new agent IDs, autoscaling groups that recycle instances, reused hostnames and IPs, and CMDB records that outlive their hardware.

Figure 3. Four tool records resolve to one entity with its cited neighborhood of services, identities, data and network boundary. The dashed replica is a coverage gap: seen in logs, absent from every inventory. Example IDs are illustrative.

Most security graphs are designed by a product team: the schema is fixed in advance and filled from scans and integrations. Ours is built by the mapping agent as it investigates one customer. It chooses the schema, works out which records across dozens of sources describe the same thing, cross-checks each claim against the other sources, and reasons its way to facts no scanner reports, such as owners and business importance, citing the evidence for each. Every entity traces to a system of record and every property cites its records. A host that appears in deploy logs and Slack but in no scanner becomes a recorded gap with its evidence instead of a node, and these gaps are some of the most useful things the system produces. The graph holds entities, typed edges and anything you would query by structure. Pages hold the interpretation, meaning findings, rationale, judgment and open questions, and they point into the graph by entity ID. The schema sits at the level people think in, such as services, datastores, identities and trust boundaries, with the thousands of instances behind each service kept as evidence.

The pre-training store is one of several. Post-training agents publish to their own stores, each agent has a private working store, users and the security team have scoped stores for preferences and curated policy, and skills live in a shared library. A single access layer in front of all of them enforces who can read and write each one.

Every run is a checkpoint

Each run starts from the promoted world model, so many runs are worth more than one long one. A single long run would hit several problems:

• The long-running agent. A run's context fills up long before a large company is mapped, so the agent starts summarizing its own work and losing detail. Anthropic describes the same problem in long-running coding agents.

• The unlucky trajectory. An early wrong turn, such as trusting a stale CMDB, shapes everything that follows, and a single run can't back out of it. As LLMs Get Lost in Multi-Turn Conversation puts it, "when LLMs take a wrong turn in a conversation, they get lost and do not recover."

• Too wide for one pass. About fifty connectors and thousands of assets don't fit in one context or one budget. The work has to go broad first and deep later.

• No clear termination condition. Mapping an environment has a goal, an expert's picture of it, but there is no point where an environment is done. The model's own sense that it has finished is the wrong signal to stop on.

• Premature termination. Given an underspecified task, models fill the gaps with assumptions and commit early. In the same paper, models that attempted a full answer early scored about half as well as those that waited.

• A moving target. The environment keeps changing, most of all in a customer's first weeks, while new data sources are still being connected.

• No checkpoint to fall back on. A single run produces one result at the end, so a regression halfway through can't be caught or undone. Separate runs give separate versions that can be scored on held-out questions and rolled back.

Many shorter runs avoid all of these. Each starts fresh from the best version so far, a bad run is never promoted, and the decision to keep going comes from the scores, not from the model's sense that it is finished. No run relearns names and inventories, and each spends its budget on what is least understood. Early runs go broad. Later runs go deep on what is still thin or contradictory, such as an identity provider nobody has reconciled with the cloud accounts, or a business unit missing from the CMDB. The mapping agent's prompt tracks progress by coverage: "a dimension nobody has touched is still in its breadth phase on run 50." The environment changes between runs, so each run also rechecks existing claims.

Each run works in its own scratchpad, a folder that holds its full trace, a summary, and a short note for the next run on what to investigate and which sources proved unreliable. Runs that follow the note tend to dig the same hole, so we treat it as one suggestion among several. Before reading it, each run checks every source and picks the least-explored area for itself. The note is also a summary, and summaries lose detail. So the scratchpads keep every run's full trace, and the note points into it.

Each run produces a new version, and downstream agents read the promoted one: the version that scores best on held-out questions, whether or not it is the latest. Training runs choose checkpoints the same way, by held-out score rather than recency. A new version is promoted only when it beats the current one by more than the usual run-to-run noise.

Each version is scored on three signals. The first is new or corrected claims, counted after deduplication against the promoted version, that a separate check ties to a source. The second is coverage of the dimensions the agent is held to. The third is a set of held-out questions written with the customer's security team from things they already know ("who owns the payments database?", "which services can reach the signing key?"). The questions live outside every store the mapping agent can read, so it never sees them, and each answer carries a validity window, because owners and configurations change. Selecting versions on the same questions over and over still leaks information, so a second set is held back and never used for promotion. Building these question sets is the slowest part, because no two environments share one.

Figure 4. Illustrative, not measured data. The promoted version changes only when a run scores higher on held-out questions, so a regressed run never reaches downstream agents. Cadence drops once gains flatten and rises when a new source is connected.

A run that fails promotion can still have seen something true and urgent, such as a decommissioned host or a new owner. Changes like these are checked against their source records and applied to the promoted version directly, so freshness doesn't wait for the next promotion.

The same score sets the schedule. A new world model improves quickly over the first several runs and then flattens, and once gains stay below a threshold, mapping every few hours wastes compute. Mapping drops to daily and speeds back up after a large change, such as a newly connected scanner or a cloud migration.

Runs also keep the wiki tidy. Stable findings move into hot/ with their backing detail in cold/. When a current note proves wrong or stale, the agent rewrites the conclusion and keeps the old evidence in cold/ and in earlier run scratchpads. A periodic compaction pass merges near-duplicate pages, splits oversized ones and retires pages past their stale_after date. Rewriting a whole wiki at once tends to lose detail, so it edits one page at a time and has to pass the same evaluation as any run.

Within a few days of continuous runs, a customer's world model can hold thousands of checked claims. Over the following months, the customer's security team adds held-out questions that grade it and reviews the rules built on it. The base model is the same one everyone can use. The world model, the questions that grade it and the rules on top of it are specific to each customer, and the longer they run, the harder they are to replicate.

Post-training agents and verifiers

A pre-trained world model is useful before any post-training, the way a base model is with a good prompt. A general agent reading it can answer many of the questions a security team asks every day: who owns this system, what is internet-exposed, what depends on this database, which of these four names is the same machine. A new use case usually needs only an objective and a post-training agent, with no new data pipeline.

Post-training does two things. The first is depth. A post-training agent spends its whole budget on one hard problem, such as exploitability analysis or container lineage, and works through it on its own, reasoning across sources and checking each step against them. In exploitability analysis, that can mean chaining an exposed service, a stolen credential and a misconfigured permission into an attack path that no single tool would show. In container lineage, it can mean tracing a CVE in a running container back through its layers to the build that introduced it and the team that owns that build. The second is fit. Some answers depend on a team's judgment, such as which systems count as crown jewels or which rules should apply, so the agent proposes and people confirm, edit or reject. Post-training agents use the world model to decide where to look. Before they publish anything, they check it against the original source records, so a mistake in the world model doesn't end up in a finding. A gap in the world model can still make an agent miss something.

Candidates are sampled independently. A separate verifier tests each one against the source systems without seeing how it was produced. Candidates are ranked by a score that penalizes the verifier's uncertainty, and the winner has to beat the published version on fresh held-out records. Strictly, this is verifier-gated best-of-N: selection at inference time, with no gradient learning. It can only pick from what the generator samples, and it is only as good as the verifier.

Figure 5. Verifier-gated best-of-N. Candidates are sampled independently and scored by a blind verifier, and the winner replaces the published version only if it does better on records it was never tuned on.

Policies: reason once per rule, apply to every asset

Policies are the part of post-training customers work with most directly. Each policy covers one attribute the rest of the product depends on, such as asset criticality, data sensitivity, environment, internet exposure, compensating controls, asset ownership or work routing. Rules fill in a policy. Each rule is a plain-language statement backed by a little decision logic, tests and cited evidence. A simple one reads "hosts named prd- run production," citing a CMDB naming standard and an EDR host group, and ignores the AWS environment tag, because the agent found that it contradicts both of those sources on almost a third of hosts. Another reads "prefer the code owners of the repository that deploys a system over the CMDB owner field," because CMDB owner fields are often set at launch and never updated. For crown jewels, the agent proposes candidates and a person confirms them, since that is a business decision.

The policy agent proposes rules with the Figure 5 pipeline, and like every post-training agent it uses the world model to decide where to look while citing only source records. A separate gate agent re-derives the answers from the vendor systems before anything is published, and published rules arrive as suggestions that a person trusts, edits or rejects. People can also write their own rules in plain language. Agreeing with the sources only makes a rule consistent with them, and the sources are often wrong, which is why a person reviews every rule.

Once a person trusts a rule, applying it everywhere is cheap. The model does the expensive reasoning once, when it writes the rule, and what runs on every asset is a small compiled expression. The rule becomes an expression the data platform can run and is checked on a sample of customer data. It may change only a bounded share of existing values, erase almost none, and leave no asset without an explanation or citation. The regular batch ingestion job then applies it to every asset with no model call per asset, and each asset gets a value plus an explanation naming the rule and its evidence.

Figure 6. One policy rule from discovery to every asset, with the reasoning done once per rule. Example rule and hostnames are illustrative.

Exploitability: can an attacker actually get there?

Exploitability is the most open-ended task. The agent takes structure from the world model (what is internet-facing, which identities and routes exist, which systems are crown jewels) and makes read-only live checks wherever current state matters. Each run tests at most one candidate path to one crown jewel, trading breadth for the depth of checking each step properly. A path starts at an internet-exposed service or at a credential with evidence that it works from outside, and paths from an assumed internal foothold aren't published unless the evidence shows how an attacker would get one. For each step, the agent asks whether the source can reach or act on the target, whether the required condition holds (including whether the vulnerable code is loaded and the exploit's preconditions are met), what action follows, which control could stop it, and what observation supports the answer. Whether vulnerable code is actually running comes from runtime data customers already have: EDR and container sensors report which libraries each process has loaded and which ports it listens on. Where that data is missing, the step stays Unknown. Weaker sources can suggest a step but not decide it.

A path is published only as an actionable finding. Every material step has current support, or exactly one decisive gap is named with the smallest check that would close it, and the finding includes the change that would cut the path. A mechanical check then confirms that it is a well-formed path to a single crown jewel, that every step refers to entities and relationships in the current world model, and that all cited evidence came from tool calls made during that run. This check confirms where the evidence came from, but it can't confirm that the path is real. A run that finds nothing is a fine outcome, and the paths it rules out are recorded so later runs don't test them again.

Container lineage: route each CVE to the team that can fix it

Container lineage answers two questions about every vulnerability in a running image: who has to fix it, and what do they change? It runs as four agents that share one store and graph. An image mapper runs every hour and records which images run where, the base image, repository and build pipeline behind each, and what each scanner reports. A curator groups findings into remediation campaigns, an updater keeps those campaigns current as fixes land, and a reporter writes a daily summary for security and infrastructure leads.

The hard part is working out which layer of an image introduced each vulnerability, and some evidence counts for more than others. The strongest evidence is a signed record from the build system of exactly what went into the image (build provenance, in SLSA terms). After that come an exact parent image digest, layers shared with a known base image, and the base image the build says it used. A matching tag or today's Dockerfile is only a hint, because a Dockerfile doesn't prove what an image built three months ago actually used. Once the layer is known, the curator decides where the fix belongs (Figure 7).

Figure 7. Each finding is assigned to the place its fix belongs before findings are grouped into campaigns. A finding the evidence can't place stays unresolved.

The output is a campaign: one project that fixes many findings at once. A campaign might cover three services pinned to an old version of a web framework, with the owning team, the current and target versions, the pipeline that rebuilds them, and how to test and roll back. A campaign for a shared base image lists every image built on it that needs a rebuild. When no upstream fix exists, the options are removing the package, switching to a different base image, adding a compensating control, or a time-limited exception. A reviewer and then a separate verifier check each campaign, and missing evidence always counts against it.

Figure 8. Three post-training agents at a glance. Each has its own verifier and re-derives every published claim from source records.

Much of security is verifiable

Jason Wei calls it the verifier's law: "the ease of training AI to solve a task is proportional to how verifiable the task is." It explains why reinforcement learning moved fastest on math and code. It also applies to selection, within the limits of what the generator samples and how independent the verifier is. Most enterprise knowledge work is hard to verify, and many security questions are not.

In application security, a sanitizer report on an input that can be replayed is a mechanical signal for memory-safety bugs, strong enough to check whether a bug was found, whether it reproduces, and whether a patch removes the crash. The signal works in one direction only: a clean run is unknown rather than fixed, and a patch can silence the crash without fixing the bug. Logic and authorization bugs have no such oracle. Infrastructure has its own checks.

Whether a principal can take an action depends on every policy that applies: identity and resource policies, service and resource control policies, permission boundaries, session policies and VPC endpoint policies, evaluated with their conditions for a given request. AWS uses an SMT-based engine, Zelkova, to prove properties of policies like these. Azure RBAC and Google Cloud IAM use different policy models, but the same kind of analysis applies to them. Whether a flow reaches a port can largely be computed from configuration: route tables, security groups, network ACLs, transit gateways, load balancers, endpoints, firewall rules, and Kubernetes network policies where the cluster enforces them. Host firewalls, service meshes and application-layer auth sit outside most of these engines. The cloud provider and Kubernetes map an IP to a workload at a point in time, and that time has to be recorded, because pod IPs are reused within minutes. Kubernetes Services map a port to pods, and the EDR, where a sensor is installed, maps a listening socket to a process.

Most attributes that look like judgment calls are a verifiable core wrapped in a judged shell. Crown-jewel status is a judgment, but whether a system stores regulated data, sits on the payment path or holds signing rights on production artifacts can each be checked against a source. Post-training moves as much of each answer as it can into the checkable part.

Verifying attack paths step by step

Attack-path analysis tends to go wrong in two ways. It treats anything reachable as usable: an internet-facing service with a CVE in a library it never loads, or a stolen key that only works from inside the VPC, shows up as a path no attacker can take. And it treats anything unreachable as safe, even though reachability is a snapshot, and an attacker with the right permission can change the configuration and create the path. Each kind of step needs its own evidence: runtime data for a software flaw, the network model for a hop, policy conditions for a credential, and the IAM engine for a permission.

The world model supplies the state, and each attack step is an action. Verifiers check the action's preconditions, apply the action to a copy of the configuration, and check the result again. This is what-if analysis: what becomes reachable if an attacker, or a fix, changes the configuration? The state covers the attacker's identity, location and credentials, the configuration, the controls in force and the time window. The agent proposes a path and the smallest questions that would confirm or refute each step, and specialized verifiers answer them. Cloud providers' reachability tools answer whether one resource can reach another in the network as it is today. What-if questions need an offline model built from a configuration snapshot, such as Batfish, which models routers, firewalls and cloud networks. Policy engines handle IAM, and orchestration and EDR data show which workload sits behind a port. Each answer is Proved, Refuted or Unknown relative to a specific snapshot and to what that engine models, with a receipt recording the snapshot, validity window and assumptions. Inference cannot override it. Receipts are written back into the world model as cited, versioned facts. Later runs then start from checked claims, can see which have expired, and are much less likely to build on the system's own mistakes.

Take a public image service with an SSRF vulnerability on an instance that still allows IMDSv1, so the SSRF can return the instance's role credentials. The service can't reach an internal admin API, and only that API's security group is in the way, so a static graph query stops there. The IAM engine proves the stolen role can add an ingress rule to that group, and on a copy of the configuration with the rule added, the network model finds the API reachable. Whether the SSRF can send the requests the API needs comes from testing the application, so that step may stay Unknown. Fixes are tested the same way. Enforcing IMDSv2 helps only if the SSRF can't send a PUT with custom headers, while denying ec2:AuthorizeSecurityGroupIngress to the role breaks the path either way, and each fix is checked to confirm that normal traffic still flows.

Figure 9. Agents propose, verifiers decide. Every verdict carries a receipt, and receipts join the world model the next run starts from.

Why better models don't make this unnecessary

Better models keep simplifying agent harnesses. Still, no model knows which of a customer's services holds payment data, who answers a page about it, or whether a given role can modify a given security group today, and no capability lets it assert that without checking. Someone has to learn each environment, keep that understanding current and check it. The world model, the held-out questions and the accepted rules all carry over to the next model, which reads them on day one.

Where this goes next

Today's loop is an inner loop. Each run reads the history of earlier runs and proposes a new version of one customer's world model, which is kept only if it scores better. That is the Meta-Harness pattern applied to the world model instead of to harness code, and the agent already edits part of its own harness through the skills and memory it writes. A Meta-Harness-style outer loop would rewrite the parts people design today, such as which sources the mapping agent samples first, what belongs in hot/, and what each post-training agent is told. That search needs a reward, which enterprise settings usually lack because each customer environment is its own test set with no public benchmark. Verifier receipts and held-out questions are the closest thing we have to a checkable reward local to each customer. Rewarding receipts alone could teach the agent to ask only questions it can prove, so coverage stays part of the score, and the held-back question set is what keeps the outer loop from overfitting the one test set each customer has. We think that makes a per-customer meta-harness feasible, and it's what we're working on next.

Some problems are still open. A fact can be correctly cited and out of date, and validity windows only partly cover that. Held-out questions are the most trustworthy evaluation and the most expensive to write. A system that reads Slack and Jira and keeps durable notes lets a prompt injection persist across runs. Agents treat what they read in tickets, chat and docs as information to weigh, never as instructions to follow, and their live checks are read-only. A ruled-out path needs the same provenance as a finding, because injected text could otherwise steer agents away from a real one. Continuous pre-training also costs real compute and has to keep paying for itself in time saved downstream.

If you want to work on hard problems in agents, harnesses, memory, verification and models, we're hiring. Reach out to us.