Remembering Decisions, Not Just Content: The Missing Layer in AI Workflow Systems
Why the edits professionals make to AI output are the richest context a system can learn from
This is the approach we’re taking at Antela.ai, an AI-native platform that automates workflows for commercial real estate brokers, from listings and offering memoranda to amenities maps and brokerage intelligence. The ideas below apply to any domain where AI drafts and professionals revise.
Most AI systems are good at remembering content. Documents, prior outputs, and conversation history are all stored, indexed, and retrievable. That solves a real problem, but it isn’t the hard one.
The harder problem is remembering decisions.
The revision is the richest data you have
Say an AI generates a marketing package for a listing, and the broker changes:
- the property positioning
- the selected comps
- the investment highlights
- the visual hierarchy
- the language used to describe the opportunity
A conventional system sees a revised document. It stores version 2, perhaps next to version 1, and moves on.
A learning system should see five distinct signals about how this broker, and this brokerage, make decisions. Each edit is a small piece of evidence about a preference, a constraint, or a piece of judgment that never appeared in any prompt or template.
Content tells you what was produced. Decisions tell you what was chosen, and what was rejected in favor of it.
Three layers of context
When I think about the context an AI system needs to automate complex workflows, I find it useful to separate three layers.
1. Content. Templates, listing data, prior offering memoranda, market data, and previous listings. This is the layer most systems handle well, usually through retrieval over a document store or database.
2. Decisions. The delta between what the system proposed and what the human approved. Which comps were swapped out, which sections were reordered, which phrases were rewritten.
3. Learned context. The generalized, scoped, durable understanding derived from many decisions: “this broker leads with tenant credit quality,” “this brokerage never uses certain superlatives,” “for industrial listings this team prefers recent sale comps over lease comps.”
Most systems stop at layer one. A durable system treats layers two and three as first-class infrastructure.
At Antela.ai, this is the architecture we’re building toward: generating marketing packages from structured representations so that every broker edit becomes a learnable signal.
(Insert the Content → Decisions → Learned Context graphic here. Caption: “Most AI captures the first. Durable systems capture all three. Antela.ai”)
Why you can’t just ask for the context
The obvious objection is that you could document all of this: write a style guide, fill out a preferences form, put it in the system prompt. In practice that fails for three reasons.
Much of professional judgment is tacit. Brokers often can’t articulate why they swapped one comp for another; they just know it was the wrong comp for this buyer.
Preferences are conditional. A rule like “always lead with cap rate” holds for a stabilized multifamily asset and fails for a value-add office conversion. Static documentation rarely captures the conditions.
Documentation drifts. A style guide written in January is stale by June. Behavior observed in the workflow is always current.
Learning from decisions sidesteps all three: it captures tacit judgment, preserves the conditions under which a choice was made, and stays current by construction.
Capturing decisions as structured signals
The technical foundation is treating edits as typed events rather than text diffs.
Get Amitesh Sinha’s stories in your inbox
Join Medium for free to get updates from this writer.
A raw text diff tells you that characters changed. A decision signal tells you what kind of choice was made. Roughly, each signal needs:
DecisionSignal {
artifact_type // OM, flyer, listing description, amenities map
field // positioning, comps, highlights, layout, tone
action // added, removed, replaced, reordered, rewritten
before / after // structured representation, not just text
context // asset class, market, deal type, audience
actor // broker, team, brokerage
timestamp
}The hard design work is in the structured representation. If comps are stored as an ordered list of references rather than a rendered table, then “replaced comp A with comp B” becomes a queryable event, and you can later ask what attributes comp B had that A lacked. If layout is expressed as a hierarchy rather than raw CSS, “moved the investment highlights above the property description” is a signal rather than noise.
This is an argument for generating artifacts from structured intermediate representations rather than directly producing final formatted output. The structure is what makes edits legible to a learning system.
From signals to learned context
A single edit is weak evidence. It might reflect a durable preference, or a one-off exception for one deal. The system’s job is to work out which.
Scope matters. A signal can be a statement about a broker, a team, a brokerage, an asset class, or a market. The same edit might reasonably generalize at one level and not at another. Keeping an explicit scope hierarchy, and promoting a pattern upward only when evidence accumulates across people, prevents one broker’s quirk from becoming company policy.
Evidence should accumulate, not overwrite. Treat learned context as hypotheses with confidence, not facts. Repeated, consistent decisions raise confidence; contradicting decisions lower it. Recency weighting handles preferences that evolve.
Conditions are part of the pattern. The unit of learning should be “in context X, this actor prefers Y,” not “this actor prefers Y.” Without the condition, you get confident but wrong generalizations.
Exceptions are information, too. When a broker overrides a learned preference, that is a signal about the boundary of the preference, not just a failure of it.
Applying learned context
Learned context only matters if it changes what the system does next. There are a few places it can enter the pipeline:
- Generation: conditioning the model on scoped, relevant learned preferences, retrieved by context rather than dumped wholesale into the prompt.
- Selection and ranking: for things like comps or highlights, learned preferences can reorder candidates so the choices a broker would have made rise to the top.
- Defaults: layout, tone, and structure defaults shift per broker and brokerage, so the first draft starts closer to the final one.
- Validation: hard organizational rules, like compliance requirements, belong in deterministic gates rather than learned behavior. The line between “learn this preference” and “enforce this rule” should be explicit.
How you know it’s working
A learning system needs a feedback metric of its own. The most direct one is the edit burden: how much does a broker change between the first draft and the approved version, and how does that trend over time for a given broker and artifact type?
If learned context is working, the volume and significance of edits should fall, and they should shift from “fixing the system’s judgment” to “adding genuinely new judgment.” Tracking that over time, segmented by field, also tells you where the system’s understanding is strongest and weakest.
What can go wrong
- Overgeneralization: treating one deal’s exception as a standing preference.
- Feedback loops: if the system’s defaults shape the broker’s edits, learning from those edits can reinforce its own biases. Distinguish active choices from passive acceptance.
- Boundary violations: one organization’s learned context must never leak into another’s. Tenant isolation is a hard requirement here, not a nice-to-have.
- Opacity: if a broker can’t see or correct what the system believes about them, trust erodes quickly. Learned context should be inspectable and editable.
The real challenge
The technical challenge isn’t generating the next artifact. Generation is increasingly a solved capability.
The challenge is building a system that progressively understands the organization creating the work: its preferences, its exceptions, and its judgment, most of which have never been written down anywhere.
Templates provide context. Data provides context. Previous listings provide context. But human decisions provide the layer that turns a capable generator into a system that works the way your team does.
That’s the layer I think durable AI workflows will be built on.
If you’re a CRE broker or team lead interested in AI that learns how your brokerage actually works, take a look at Antela.ai. If you’re building learning systems in other domains, I’d like to hear how you’re handling decision capture. Leave a comment or connect with me on LinkedIn.
Amitesh is the founder and CEO of Antela.ai. He has 20+ years of experience in software engineering, architecture, and engineering leadership, holds an MBA and an MS in Computer Science, and guest lectures in graduate entrepreneurship courses.
