Wissen AGL

This is part of the "SOTA Retrieval - What next?" series.

AGL - Analyst Guided Learning: A self‑improving planning layer that turns every analyst “👍” into reusable expertise.

The base conjecture here is that the models like o3, Gemini 2.5, o4-mini are smart enough to conduct "most" types of analysis. The biggest missing piece at the moment is the output does not follow the structure and/or the specific areas of analysis the user wants to focus on based on their thesis. If the user's could write really good prompts and had access to a SOTA retrieval system this wouldn't be a problem. But writing good detailed prompts is hard work, and retrieval systems like that don't exist outside of Wissen - hence we focus on helping generate really high quality "plans" which are effectively natural language prompts. This also contains retrieval steps and basically allows the user to insert their expertise, whilst allowing our system to learn their preferences from their edits - effectively mimicking their expertise over time.

Why this is great HCI?

The interface works because it exposes every part of the agent’s workflow: sources, planned steps, and live execution. So analysts can verify or edit each element without opening a code editor. A single “Like” marks a run as the preferred way to handle similar tasks, feeding the agent precise feedback with almost zero effort. This tight loop gives the agent clear training signals while keeping analysts in full control of data, tools, and decisions.

Questions for King:

1. Do you understand what it is? Is it clear enough?
   1. @King: Not fully. It feels more like the 'meta' rather than what is actually being built i.e. the approach to letting analyst guide LMs rather than what they are actually guiding in implementation. It'd be good if there were some examples of this so it can be more easily conceptualised.
2. What do you think about it conceptually, so moving away from my implementation of it via the user interface suggestions what do you think about the idea overall?
   1. @King: I really like the frame of o3 etc. are good enough models and strongly agree with the idio'ing + what you've idio'd out as the 'last mile delivery'.
   2. @King: what's not clear to me is the extra requirements of prop data (i.e. is that vol we want to incur ASAP and is that necessary to produce value/test our hypothesise?)
3. What do you think about my implementation suggestion of it? It is intentionally vague at the moment but how would you think about the design of it? How would you steel man the case?
   1. @King: it'd start from the premise of what we (will soon) have first and what does that mean -> draft variants.
   2. @King By this I mean we will have 5y worth of histories for {n} number of equities - what conceptions of 'AGL' and/or utility points can analysts capture (we won't have prop data)? Then are there certain 'nodes' information that analysts consistently try to 'structure' today but just takes a long time and can that be what we initially showcase? Think that way we'll guide ourselves to more concrete hypothesise (that we can defend internally) and ship
   3. @King: I'd need to see some 'drafts' of it visually otherwise find it hard to conceptualise what components mean/fit in (even if it is as simple as chucking this into bolt.new -> showing a few variants will help with giving more tuned feedback/thoughts)
   4. @King: a lot of the 'aha' UIs is just going to be a function of how many versions have we rinsed through (quickly) that were just not 'aha' i.e. we didn't feel like it was 'it'
4. What do you think about the technical complexity of it? Manageable? Too complex?
   1. @king: prop data is not a vol i think we should take immediately (unless it's necessary) - that's because it's one of those that we cannot control (yet) and a better sizing in will be if we can use the data we have today -> produce value and then size into prop data (we are able to gain more conviction on guarantees product wise ahead of time whereas with prop data we cannot until we implement)
   2. @king: i'd need to see sketches visually to know/feel complexity of it, however overall feels somewhat workable (again latter comment is because it's abstract so hard to formalise into a high conviction view)
5. What more information do you need from me to better understand the utility of it? What haven't I thought enough about?
   1. @king: my comments above covers them - i think if you start from the place of 'what do we have' rather than 'what more can we have', it'll make the path to commercialisation (time + quality of it) much faster e.g. prop data is not a vol i think we should assume right away (unless absolutely necessary in the first instance of our product) rather it's the 'natural next step' after
   2. @king: sketches - some formalisation of the implementation is always a good way to see it (needn't be perfect) and also can have multiple variants, but that concretisation will help a ton on understanding complexity and also testing whether the conjectured implementation is really 'it'
   3. @king: general - i would decouple and make clearer 'property desired' and 'implementation' as this gives more space on improvements + changes + idea generation. specifically the property you're stating that is of value (which I agree) is analysts can/should be able to easily tailor the expected output they get, whether or not 👍 is the right implementation is a (?) and should be a (?) which then gives space to spec' out more representations of that same property without being wrapped into one way of going about it. this also separates out the conjectures (and testing of) more cleanly i.e. 'we think enabling analysts to tailor outputs will unlock {x}' and 'the best way to do that is 👍'. Latter is prone to change, former should not really as it's the premise of work.