October 14, 2026Main stage6 min read

Your Company Has No Model of Itself: Bootstrapping a World Model from Slack, Decks and Meetings

A green status slide can conceal a project already slipping. Joao Wenzel describes a system that tracks what a company believes, how old the evidence is, and what happens next—then asks people to correct the beliefs that matter.

Joao WenzelCitadel SecuritiesCOO

From the conference livestream · 6:38:33–6:57:11 on YouTube. The player starts and stops at this session’s boundaries.

6:38:33 ↗

The colleague who knows how the company works

Every company has someone who seems to know everything. They have survived the reorganizations, remember why a project changed direction, and can predict what a strategic move will actually do. Joao Wenzel calls that person a company's world model. They are useful, but they do not scale, and much of what they know never gets written down.

At Citadel Securities, agents were already helping with engineering when leadership began asking whether they could also help define and refine strategy. That requires context beyond the latest document. An agent needs to understand relationships between teams, a project's history, and the difference between what people say in a room and what remains unsaid.

Top-down records offer a clean view: strategy documents, status decks, and formal reports. They also contain interpretation and incentives. Wenzel calls the result a watermelon project—green on the outside, red on the inside. Bottom-up material such as Slack, meeting notes, code changes, and agent-session traces is noisier but can reveal what is actually happening.

He borrows the idea of a state estimator from robotics. The system maintains a belief about a project, becomes less certain as that evidence ages, and updates the belief when new observations arrive. It needs to consider how old a signal is, where it came from, whether the source is still working, and whether other sources agree.

6:42:28 ↗

Read both the slide and its underlying text

Extracting a monthly status deck sounds simple until the details matter. Parsing a PowerPoint file gives you XML, but interpreting a green status cell through raw color codes is awkward. Sending a screenshot to a vision model preserves the layout and color, yet text can become hard to read—especially when someone pasted an earlier screenshot into the presentation.

Wenzel combines the two. The image carries spatial and visual meaning; the underlying text supplies the words and numbers the vision model might misread.

A project-status slide is paired with its underlying XML text, linking visual color and layout to the words about failing tests and a threshold.

Source frame at 6:43:30. The two representations resolve different ambiguities in the same record. Neither has to carry the entire extraction task alone.

Even a correct extraction is only a snapshot. A project can change names between months. A deck can be five days old while a Slack reply includes a dashboard that contradicts it. The system needs continuity across those records, plus a way to reconcile the newer evidence with the older claim.

6:44:34 ↗

Update the belief without rewriting the past

Wenzel's loop has five stages: update, age, observe, grade, and correct. Agents participate throughout, but their proposals do not directly become authoritative records. Code and people decide how the stored state changes.

World-model loop connects update, age, observe, grade, and human correction, with distinct workers for reconciliation, source reading, and backtesting.

Source frame at 6:45:10. Reading sources is one part of the loop. The rest keeps track of time, tests the beliefs against later events, and incorporates correction.

An update compares last month's record with this month's slide. Wenzel describes building three years of those historical records. If a project changes its name, continuity in the people and goals can help identify it as the same project. In his example, the record retains both Northstar and Atlas Ledger Migration under one project ID.

The update also separates the reported status from the status supported by evidence. A deck says green, but an unresolved dependency in its comments supports yellow. The record preserves both values and the reason for the disagreement.

Previous months remain unchanged. A later correction enters the record going forward instead of silently repairing history. That preserves what the system could have known at the time—a requirement for evaluating whether its warnings were useful.

Claims also carry their age. A proposed go-live date that has already slipped twice should not reach the agent as an undated fact. Wenzel reports that, in the historical delivery dates his team examined, roughly half changed within two months, and most changes moved the date later. The point is to supply the age and revision history that make a date interpretable, rather than treating every stored claim as equally current.

6:48:34 ↗

Use the future to grade the warning

The first attempt at reading the accumulated material was to give a model the entire corpus and see what it found. Wenzel says that lost too much detail. The team instead used specialists to inspect different material and other agents to review their findings. He reports that useful project updates more than doubled in that comparison.

The next test is harder: does a warning tell leadership where to look before the status officially deteriorates? Historical snapshots let the team ask what the system would have concluded as of a past date, then compare that conclusion with what happened afterward.

The shown backtest compares green projects that the system flagged with green projects it did not flag. Within three months, the slide shows 18 out of 100 flagged cases turning yellow or red, compared with 10 out of 100 unflagged cases.

Backtest slide compares 18 per 100 flagged green statuses turning yellow or red within three months with 10 per 100 unflagged green statuses.

Source frame at 6:50:20. That is roughly twice the rate in this comparison. It supports using the flag to direct attention; it does not mean the system knows exactly what will go wrong, or that most flagged projects will deteriorate.

People provide another kind of correction. Wenzel emphasizes meeting them in the tools they already use and making the question easy to answer. A correction to one fact repairs one output. A correction to a rule can improve every output governed by it, including future ones. The record distinguishes what an agent inferred from what a person actually confirmed.

6:51:39 ↗

A missing sensor is not a quiet project

The bottom-up sources describe different parts of the work. A meeting captures what people say aloud. A Slack thread connects claims with participants and attachments. A pull request records what changed. With an engineer's opt-in, agent-session traces can reveal the evolving request, failed tests, and decisions that preceded the pull request.

Each source also has a failure mode. Wenzel uses a disappearing speedometer as the analogy: losing the reading does not mean the car has stopped. The team encountered the same mistake when a channel appeared to go quiet because the source was no longer supplying usable observations.

The record on his slide keeps two dates per source. This excerpt shows the difference between trying to read Slack and actually receiving a good result:

json

{
  "slack": {
    "last_tried": "2026-03-16",
    "last_ok": "2026-02-20",
    "state": "unseen"
  }
}

Source record at 6:53:40. The system attempted a recent read, but its latest successful observation is older. It should lower confidence in what it knows, rather than infer that nobody is discussing the project.

Together, the sources can produce a more useful account than a green cell: the go-live date slipped twice, the evidence supports yellow, and people are discussing failing tests. Leadership conversations can begin with that disagreement instead of asking everyone to scan the same deck. Wenzel describes weekly readings for managers and a shared context layer other agents can use, with similar ideas being explored for understanding client needs.

6:55:00 ↗

Ask people where their answer can change the outcome

Two problems remain open. One client can have four records in four systems without a shared identifier; Wenzel says the team does not yet have a clear, elegant answer to resolving those identities. The other problem is choosing when and how to ask stakeholders for help.

His decision depends on both confidence and stakes. If the stakes are low and the model is sure, apply the update automatically. If the stakes are low but the model is unsure, wait for more evidence. High-stakes changes deserve a person: ask the owner to resolve uncertainty or confirm the proposed update. Only a person's answer makes a record confirmed.

That is the model Wenzel wants companies to build: a changing estimate of their own state, evaluated against what happens next and corrected through usable interactions with the people who know the work. Collecting the history gives those evaluations something to test. Preserving uncertainty keeps a missing source, stale deck, or unresolved identity from becoming a confident answer.

Full transcript 339 timestamped passages

Machine transcription with reviewed terminology and names. Some recognition errors may remain. Timestamps refer to the original livestream.

6:38:33Okay.

6:38:34Pleasure to be here.

6:38:36Another round of applause for everyone at AI Engineering.

6:38:39This has been a really, really exceptional conference so far.

6:38:42Thank you.

6:38:44All right.

6:38:45So I want to begin by asking you to think about that person in your company who just

6:38:49seems to know everything.

6:38:51They've been through 17 reorgs.

6:38:53They know all the gossip, all the politics.

6:38:55and somehow they always seem to predict what's going to come out of these big strategic moves.

6:39:01That person is a company's world model, essentially.

6:39:05And the problem is that they don't scale and nobody really writes down what they say.

6:39:11I'm João Wenzel with Citadel Securities

6:39:14and I'm going to talk a little bit about how we try to approximate that with an agentic system.

6:39:21So a little bit about Citadel Securities.

6:39:22we build our own technology down to the silicon.

6:39:26At this point, over two-thirds of our employees write code.

6:39:30So naturally, we are completely AI-pilled,

6:39:33and agents already help us with a lot of things at the organization.

6:39:38So naturally, leadership started asking questions about strategy.

6:39:42These harnesses are really good at producing high-quality code,

6:39:46but can they actually help define and refine the strategy of our company?

6:39:52So this is one of my favorite visuals I've borrowed from Tim Urban.

6:39:56Strategy really comes down to three questions, right?

6:39:58Where do we stand

6:40:00right now? What's going to happen next? And how did we get here? And to answer any of those questions, an agent has to have a really rich profile of the company that it's operating in. So this is broadly a talk about engineering an institutional memory layer. Let's call it that.

6:40:21The agents need to have information about relationships, right?

6:40:24Two teams that used to work together but no longer talk because there was a reorg.

6:40:29Or a project story and why it was re-scoped several times.

6:40:34Or the politics, right?

6:40:35Like, who's in the room?

6:40:37What are they saying?

6:40:37And what are they not saying?

6:40:40There's two ways in, right?

6:40:42There's top-down and there's bottom-up.

6:40:44Top down, you have the decks, you have your strategy docs,

6:40:48your meeting and status reports,

6:40:50and they're tidy and they're pretty clean,

6:40:53but there's a unique human twist.

6:40:55People generally like to infuse their thoughts and opinions

6:40:58into these things, sometimes by design,

6:40:59so you end up with things I call watermelon projects.

6:41:02They're green on the outside and red on the inside.

6:41:06Then you have, on the bottom, you have the really noisy stuff,

6:41:09which has a surprising amount of signal,

6:41:11but it's hard to uncover.

6:41:14You have meeting notes, and you have slack and coat changes,

6:41:18and even your session traces with your favorite harness.

6:41:21And the model is where they meet.

6:41:23The evidence is synthesized at that level.

6:41:26Now, the evidence piece sometimes is problematic

6:41:29because it's either partial or wrong,

6:41:31but it turns out that in robotics,

6:41:33you actually have the solution for this,

6:41:35and it's called a state estimator.

6:41:37What you do is you have some sort of belief

6:41:41about something you care about,

6:41:42and the longer it's been since you've seen or observed evidence

6:41:46that supports it, the less you trust it, right?

6:41:50The fuzzier it gets.

6:41:52Until you have a deck or some thread or some meeting note,

6:41:56that sort of collapses that and you now have new evidence, right?

6:42:00And now you're more certain of it.

6:42:02And therefore you produce the update.

6:42:05And the things that I care about when producing an update

6:42:08or that the agent should care about, there's three things.

6:42:11There's how long has it been since some signal has been received.

6:42:15There's where did that signal come from, and is it still trustworthy?

6:42:20And then does it broadly agree with other sensors?

6:42:23There's a lot of parallels here with self-driving, for example, that I'll come back to.

6:42:28So let's start at the top.

6:42:29A very simple example is something like a slide that is produced already by someone in BizOps,

6:42:36and they produce a monthly status deck.

6:42:38and the question is, how do you get data out of this slide?

6:42:42Many of you, I'm sure, have tried that.

6:42:44It's deceptive, actually, because let's say you try to parse the file.

6:42:49You unpack the PowerPoint file and you get an XML

6:42:52and all of a sudden you get into this really interesting conceptual question.

6:42:55What is green? What is the hex code for green?

6:43:00And things break down when it comes to this type of script.

6:43:03Then the solution is to say, well, I'm just going to take a screenshot of it

6:43:06and throw it at a vision model.

6:43:08But at that point, even if it's pretty high res, you're dealing with someone who copy-pasted

6:43:12a screenshot back into a presentation, and essentially you have Claude trying to squint

6:43:17and trying to figure out if it's a 31 or an 81.

6:43:20And so the theme of the talk really is about elegance comes from just synthesizing things

6:43:26and adding more information.

6:43:28And in this example, it's very basic, but you get the true picture by taking both the

6:43:33XML and the output of a vision model.

6:43:36Now, that's pretty basic, right?

6:43:38But the issue is that you want to establish some continuity over time, right?

6:43:43Like this collateral that your company accrues is very much sort of always building up.

6:43:48And so in this particular example, you have a project that just spontaneously changed names back in March.

6:43:55And so, you know, you have to establish that sort of longitudinal traceable audit layer

6:44:00as you create this shared context layer about the sort of institutional memory of your company.

6:44:07And the irony, there's two things.

6:44:09The irony here is that even if you do this really well,

6:44:12you're still missing half the picture, right?

6:44:14You're looking at a deck and your Slack says otherwise

6:44:17because that was five days ago.

6:44:19And now you have someone on Slack saying,

6:44:20hey, by the way, I think we're on track for this.

6:44:23But then someone replies with a picture of a dashboard

6:44:25and it's no longer the case.

6:44:26So things just start breaking down.

6:44:28And so we need to do a better job

6:44:31of integrating all these things, right?

6:44:34Your company has no model of itself.

6:44:37So I'm proposing just a brief plan here.

6:44:40The idea is you take the three things that I described earlier

6:44:43about the state estimator.

6:44:44You have the update, age, and observe stages,

6:44:48and then you have grade.

6:44:50The grade stage is basically comparing what you observed

6:44:53versus what you expected.

6:44:55And then the correct stage is basically a way for people

6:44:59to allow the system to get new feedback

6:45:01and steer the behavior of the system.

6:45:05At Citadel Securities, the system that we've built has agents at every part of this particular

6:45:11loop.

6:45:12But the key thing is that the model is proposing these changes, and then you have code and

6:45:16people deciding how the records are updated.

6:45:19And of course you're probably asking yourself, why not just RAG?

6:45:23Probably RAG would do the trick.

6:45:24And in fact, it really doesn't.

6:45:27In this example, I asked, hey, what's the status of this project?

6:45:30Is it on track?

6:45:31And as of March 16th, some model would happily pick up a couple of Slack messages and some

6:45:37slides and say, yep, it's green.

6:45:39But it's missing a lot of the context, right?

6:45:41It's not enough.

6:45:43So here's how we start building this world model.

6:45:46The first stage is about updating information consistently and robustly.

6:45:51In this simple example, where I'm taking some slides and some decks, we are basically just

6:45:56looking at every month.

6:45:58A new month comes around, we take last month's record and this month's slide,

6:46:03and you try to construct a sort of longitudinal record.

6:46:07And we've been doing this now for three years.

6:46:09We have a pretty large historical database of these records

6:46:13that now allow us to construct this robust so-called institutional or enterprise world model.

6:46:19You start with the basics.

6:46:22Sometimes these models struggle with the most basic things, but they're normal.

6:46:26The actual name of a particular project changed spontaneously,

6:46:31but by actually looking at that historical set of records,

6:46:34it can see and infer that it actually refers to Project North Star

6:46:38by virtue of who was involved, by virtue of some continuity in the types of goals,

6:46:43those kinds of things.

6:46:45But more interestingly, what you want to do is you have the agentic system

6:46:49try to discriminate between what's being reported and actual evidence for what it's saying.

6:46:54So you look at some status deck, for example, and here it's identifying that while it is green on the deck, in fact it should be highlighted as a yellow and should be flagged as such because there's a comment someone left talking about how there's a dependency still outstanding.

6:47:09The main thing here is that you don't touch previous months, right?

6:47:13You just sort of heal in the sort of feed-forward mechanism.

6:47:17And what that allows you to do is to actually do some robust evals down the line, right?

6:47:23So here's what the actual update step writes.

6:47:26Very simple.

6:47:27This is what it was reported.

6:47:29This is where the evidence points, and this is why.

6:47:34And then you fold in the second component, age.

6:47:38The reality is every fact has a half-life.

6:47:40We've all seen, you know, you go back at some slides,

6:47:43and you see that the go-live date for a particular project keeps slipping.

6:47:48It was Q2 in January, then it was Q3, now it's October.

6:47:52And you actually observe this.

6:47:55By actually collecting all this data,

6:47:56you can have some pretty interesting beginnings of analytical insights.

6:48:00For example, in the last three years, you look at these delivery dates,

6:48:04and on average, half the delivery dates change within two months,

6:48:07and 90% of those change into a date that is after what was originally proposed.

6:48:12So far, so good. Pretty basic.

6:48:14But what this forces you to do is then introduce this notion of a date that is associated to a particular claim

6:48:22so that the agent can introduce some sort of recency bias when you ask about the status of a particular project, person, or the corporate intent, let's say.

6:48:34Then the observe section.

6:48:36The observe section here, I'm going to pretty quickly gloss over it, but just kind of give you something very tactical.

6:48:42In the beginning, I was pretty seductive to just basically say, well, let's just YOLO this.

6:48:46Let's have Claude or some other model take a look at the entire corpus of things, and let's see what it does.

6:48:53And as it turns out, it's pretty clear that a lot of information is lost.

6:48:59It loses some attention to detail.

6:49:02And so what ultimately we had to do was engineer a simple agentic workflow

6:49:07where you have a series of specialists break down the collateral of these assets

6:49:11look for specific things, be reviewed by other agents, and so on.

6:49:16And what you see here on the right-hand side

6:49:19is that actually the amount of insightful updates

6:49:22to a particular project more than doubled after doing this.

6:49:26So I guess the takeaway here is be intentional

6:49:28about how you build these workflows

6:49:30and don't just assume that a YOLO method is going to work out.

6:49:34But now you get, I think, to the really interesting stuff.

6:49:36A world model should tell you what happens next.

6:49:39What project is about to slip,

6:49:41or which green turns red the next month.

6:49:43And it turns out that you can actually do this, right?

6:49:46Because you can look back and establish a snapshot

6:49:49as of some sort of past date

6:49:51and essentially run a backtest.

6:49:53So for example, if we take a snapshot as of February,

6:49:55we can look at the future labels that came after that

6:49:59and see and

6:50:00compare what the agent said was going to slip or flagged versus what actually happened.

6:50:05And you can see that as the agent analyzes all this information, that for statuses that were green but flagged, they were twice as likely to actually turn yellow or red.

6:50:16And so, again, this is encouraging

6:50:18because we're starting to see some beginning

6:50:20of the inability to say,

6:50:22well, it's not predictive of exactly what's going to go wrong,

6:50:25but at least it should tell you what to look at.

6:50:28So, you know, you have 18 different cases

6:50:31where you have a verdict from an agent that's flagged,

6:50:34but what about those where you don't?

6:50:36And this is where some product intuition comes in.

6:50:38First of all, how would you incorporate

6:50:39a very elegant sort of loop

6:50:41where you include an actual user, a stakeholder, a human?

6:50:46What do you ask them and where do you meet them?

6:50:49I put a nontrivial amount of work into finding out how best to actually capture this information.

6:50:55It's meeting the users where they are, whether it's the app they're using, Slack, email,

6:51:00whatever.

6:51:01The closer you can get to them and the simpler you can make that feedback collection mechanism,

6:51:05the more scalable and robust the process is going to be.

6:51:09It also matters what you ask.

6:51:10You want to understand whether you're asking a fact which only fixes one output,

6:51:16or if you're asking about a rule.

6:51:18And once an agent understands that pattern,

6:51:20it does a much better job of fixing every output it covers,

6:51:23both now and into the future.

6:51:26So we have this notion now of our record containing not just an element

6:51:32of what was inferred by the agent,

6:51:34but more importantly confirmed after someone actually provided that signal.

6:51:39Okay, so now bottom up, right?

6:51:42You have meetings with really strong signal, what people say out loud.

6:51:45You have your Slack.

6:51:47Obviously, it's constant.

6:51:48It's noisy.

6:51:49It's very close to the truth.

6:51:51Code changes describe what shipped.

6:51:53And then, of course, the Asian sessions, which is how the sausage was made.

6:51:56And I think I encourage you all to explore all of these disparate data sources to kind

6:52:00of build such a model up.

6:52:02With Slack, it's relatively simple, right?

6:52:05like you're just looking at every thread and trying to understand,

6:52:07based on attachments and participants and content,

6:52:11the claims that you want the agent to record or update.

6:52:15When was this? Who was responsible?

6:52:18Or who does this relate to? What project?

6:52:21What is the sort of link to the evidence? And so on.

6:52:26With PRs, of course, it shows you what changed.

6:52:28And it's a really nice way to see how a project is evolving.

6:52:32But when it comes to the actual subtleties of how projects are run and deployed, it's

6:52:39really interesting to look at the actual traces for users and engineers who opt into that.

6:52:44You understand how the ask evolved over time, test failures, or particular decisions from

6:52:52the developer, those kinds of things.

6:52:55Ultimately, these culminate in a pull request, but the synthesis of these things, I think,

6:52:58makes a big difference.

6:53:00The other gotcha I just want to share is to just be mindful of how you think about the

6:53:06validity of signal coming from different so-called sensors.

6:53:09If you're driving down a highway, for example, and your speedometer just disappears, it doesn't

6:53:16mean you're now going at zero miles an hour.

6:53:18It's just like a faulty signal.

6:53:20So for example, here we ran into a couple of issues sometimes when the bottoms-up approach,

6:53:24you had some semblance of a claim saying,

6:53:27hey, this particular channel, this thing is going quiet, what's going on?

6:53:31But in reality, we were treating it as a zero,

6:53:33and really it shouldn't have been.

6:53:34And so we sort of iterated over time to understand

6:53:38how to incorporate when we last tried to get information from that sensor,

6:53:43when it was last okay, and what do you do when these diverge?

6:53:48So now, if you look at the actual record that we constructed,

6:53:52the agents are going to be much more effective

6:53:54in understanding the true state of the world.

6:53:57It's not green.

6:53:59It's the go-live, slip-twice, the evidence says yellow,

6:54:02people are talking about failing tests.

6:54:04It's going to be tricky.

6:54:06So what do we use this for?

6:54:08We use it to steer leadership conversations.

6:54:10Instead of circulating a deck to everyone

6:54:13and forcing everyone to just go through some slides

6:54:15everyone glosses over,

6:54:16you start with the stuff that actually matters.

6:54:19You start where the deck and the evidence disagree.

6:54:22You also produce a weekly read for managers and leaders

6:54:25on what stuck and what went quiet.

6:54:27But I think also, most importantly,

6:54:29you have the sort of beginning of a context layer

6:54:31that every agent can rely on.

6:54:34And we're using this pattern and constructing it

6:54:36so that it's extendable to other different use cases.

6:54:39Right in our client franchise, for example,

6:54:41we're curious about how we can build similar models

6:54:43to help serve our clients.

6:54:44We know we have some client,

6:54:46and we want to understand who holds what,

6:54:49what are they interested in,

6:54:51how can we anticipate their needs as best as possible

6:54:54by folding in information

6:54:55from all sorts of disparate internal and external sources.

6:55:00So a couple of things that are difficult to do,

6:55:02just to kind of, maybe we can chat outside about your solutions,

6:55:05I'd be very curious to hear,

6:55:07are when you have a lot of, you know, for example,

6:55:10one client with four records and four different systems

6:55:12with no canonical identifier,

6:55:13how do you go about mapping those in a very elegant way?

6:55:18That's one thing that I don't think we have a clear answer to.

6:55:21The second thing is, how can we be most effective at capturing signal from stakeholders and users?

6:55:28Where the model is sure, and the stakes are pretty low, you should just apply it automatically.

6:55:33When those stakes are low, but the model isn't sure, just wait for more evidence.

6:55:38But if the stakes are high, it really matters who you ask, when you ask it,

6:55:43and kind of the whole mechanism there.

6:55:46So here's the loop again.

6:55:49Update, age, observe, grade, and correct.

6:55:53And three things I want you to take home.

6:55:55The model that your company has,

6:55:59you should think about it as a state estimator, right?

6:56:02Don't assume that just like indexing everything

6:56:05and cataloging everything is enough

6:56:07because by definition, these things are extremely nuanced

6:56:11and this intrinsic information that lives almost between the lines

6:56:14is hard for even the best state-of-the-art models to capture.

6:56:18Grade it against what happens next, right?

6:56:20So be intentional and think through how you can integrate

6:56:23and implement evals from the get-go.

6:56:25And think about an elegant solution that allows your models

6:56:29and your agents and your stakeholders to kind of play nice together.

6:56:36Your company can have a model of itself.

6:56:39I encourage you to start collecting now

6:56:40if you're not collecting already.

6:56:42And certainly if you have, if you're at a bigger company

6:56:44and like me you had the fortune or misfortune

6:56:47of dealing with thousands of decks,

6:56:49definitely something you should start thinking about

6:56:51because I've definitely seen material improvements

6:56:54in how these agents are able to reconstruct

6:56:56that sort of corporate memory

6:56:59and apply it in all sorts of daily tasks

6:57:02without sort of being all confused about things.

6:57:06Okay, thank you very much.

6:57:07I'm João and I'll be outside for any questions if you want.

6:57:10Cheers.

6:57:10Thank you.