Concepts / Designing the Application Layer Around a Model

Designing the Application Layer Around a Model

Jagged intelligence means an AI system can be brilliant on one task and surprisingly weak on an adjacent one, so strength does not transfer reliably across neighboring tasks.

  • Programming

A Feature That Worked in the Demo

When you build a product on top of an AI system, the first questions usually concern what the system can do. A feature is demonstrated, it produces a good answer, and the team feels confident. But an equally important question is how the system fails. Some failures are surprising because they do not match the system's obvious strengths. Others come from the way the system is used across time rather than from any single answer it gives. Two named failure modes matter for an engineer working in this area: jagged intelligence and anterograde amnesia.

This article follows a single idea through the design of an application. The source material draws a practical conclusion: how an engineer chooses to interpret these failure modes determines whether the application succeeds. We will look at each failure mode, trace where state goes when a session ends, and then compare the two interpretations an engineer can adopt. Only one of them leads to a shippable design.

Jagged Intelligence and Adjacent Tasks

Definition

Jagged intelligence means an AI system can be brilliant on one task and surprisingly weak on an adjacent one, so strength does not transfer reliably across neighboring tasks.

The important word in that definition is adjacent. The two tasks are close enough that a person would expect the same ability to carry over from one to the other. If a person is excellent at one task, they would usually be reasonably good at a neighboring one. The AI system does not reliably behave this way. A system that performs excellently on one task and then stumbles on a neighboring task produces a profile that looks uneven, or jagged, when plotted across the range of work it is asked to do.

The unevenness is the defining feature. The system is not uniformly good or uniformly bad. Its competence has sharp edges, and those edges do not necessarily line up with how a human would group the work. The boundary between strong and weak performance may fall somewhere a human would never have drawn it.

Why this matters for a builder: the difficulty comes from predictability. If you cannot reason from a strong result on one task to the likely quality of a close neighbor, you cannot safely assume that a feature which works in your demo will work for every input your users bring. The demo proves one point on the profile. It does not prove the surrounding region.

Worked example

Reasoning across a neighboring input

A team builds a feature that summarizes short news articles and tests it on a dozen well-formed articles, and every summary is good. They then ship it to customers who paste in other kinds of text. Should the team assume the feature works on those inputs? (This scenario is a hypothetical illustration, not a measured result.)

  1. 1
    Identify the tested task

    The demo established strength on short, well-formed news articles. That is one point on the system's profile.

  2. 2
    Identify the neighboring task

    Customer text that is similar in form, such as a longer or differently structured document, is a neighbor of the tested task. It is close enough that a person might expect the same skill to carry over.

  3. 3
    Apply the source's warning

    Because strength does not transfer reliably to neighbors, a strong result on news articles does not establish the quality of the summary for the neighboring input. The team needs to test the neighboring inputs themselves.

Result

The team cannot assume the feature works for every input its users bring. It should test the neighboring input types directly and design around any weak region it finds.

Task Atested in the demoStrong resulton Task ATask Bclose neighbor of Task AQuality unknownon Task Bshowscannot be inferred from
How can the same model succeed on one task and fail on a closely related one, and where does the boundary between strong and weak performance sit?

Anterograde Amnesia and the Session Boundary

The second failure mode is anterograde amnesia. The phrase borrows from medicine, where it describes a loss of the ability to form new memories after a point in time. In this context the analogy names a failure that happens across time rather than inside a single response. Anterograde amnesia means the system does not learn from one session to the next.

Each session begins without the lessons a previous session might have seemed to teach. Whatever the system appeared to learn in one conversation is not carried forward by the system itself. This is the key point for a builder. A user may feel that the assistant understood a preference yesterday, but if the application does not supply that preference again, the system will not know it today.

What do you think happens?

A user told the assistant their preferred units in yesterday's session. Today, in a new session, the assistant has not been given any stored preferences. What does the system itself carry forward from yesterday?

Reveal answer
Answer:

Nothing on its own. The system does not learn from one session to the next, so continuity has to come from the application around it.

The wrapper must store what matters and supply it to the model on later calls. Without that, the preference is simply gone from the system's point of view.

Tracing State Across Sessions

The source is specific about where the fix belongs. It is not the system's job to remember, because the system does not do that across sessions. The wrapper, meaning the application layer that surrounds the AI system, has to compensate. If your product needs continuity between sessions, that continuity has to be engineered in the code and data you control around the model.

Follow the state through the diagram below. In session one, the user's input goes to the model and a response comes back. The part that must survive the session boundary does not stay inside the model. The application layer saves it in a store the engineer controls. When session two begins, the application retrieves that saved state and supplies it along with the new request. The model then answers with that context in front of it.

Session one inputuser requestApplication storestate the engineer controlsSession two inputnew requestModel responsereturned to the applicationModel call withsupplied statecontext added by thewrapperproducessaved by wrapperretrieved and suppliedcombined with
Where does information go after a session ends, and how does the application layer carry state into the next call that the model cannot retain on its own?

Two Stances Toward a Failure

The source contrasts two stances an engineer can take toward these failure modes. The difference is less about optimism or pessimism and more about where effort is spent. Both stances recognize that the failures exist. They disagree about what kind of thing the failure is, and that disagreement decides where the work goes.

Failure is a defectto be eliminatedEffort aimed at themodeltrying to make it stopWrong layercycles spent hereFailure is asubstrate factto be accommodatedEffort aimed at theapplicationlayer that surrounds themodelShippable designdesigned around knownfailuresleads toends inleads toends in
How does the design differ when a failure is treated as a defect to fix versus a fixed property to route around, and what does each choice change downstream?

The Application Layer Around the Model

The concept map below shows the design logic. The named failure modes sit at the top, and the application layer is where each one is accommodated. The source is explicit that anterograde amnesia has to be compensated for by the wrapper. For jagged intelligence, the source's wording says that treating the failure as a fact of the substrate and designing the application layer around it is crucial, so the same layer is where that accommodation is expressed.

Jagged intelligenceuneven competenceAnterograde amnesiano carry-over betweensessionsApplication layerwrapper around the modelAI systemthe substrateUserbrings requests and inputsaccommodated incompensated bysends input tocalls
Which components sit between the user and the model, and what does each one contain or control?

Mistakes Builders Make Here

  • Common mistake

    Treating a strong demo as proof of general strength

    Why it fails

    Jagged intelligence means strength does not transfer reliably to neighboring tasks, so one good result says little about nearby inputs.

    Do this instead

    Test the neighboring input types your users will actually bring, and treat weak regions as design inputs.

  • Common mistake

    Assuming the model remembers yesterday's session

    Why it fails

    Anterograde amnesia means the system does not learn from one session to the next.

    Do this instead

    Store the state that matters in the application and supply it again on later calls.

  • Common mistake

    Spending effort trying to fix failures inside the model

    Why it fails

    The source warns that the bug stance spends cycles in the wrong layer.

    Do this instead

    Decide which layer of the application is responsible for each failure mode and build that layer deliberately.

  • Common mistake

    Waiting for the failure modes to disappear before building

Practice: Assigning the Failure to a Layer

MEDIUM

A team builds an assistant that helps customers plan trips. In a demo, it handles one kind of booking request well. In production, a neighboring kind of request is handled poorly, and the assistant forgets a customer's preferred seat type when the customer returns the next day. For each problem, decide whether the team is treating it as a bug or as a substrate fact, state which layer should own the fix, and explain what state the application must store.

Hints
  • Ask whether the poor handling of the neighboring request is a strength that failed to transfer.
  • Ask what carries information from one session to the next, and whether the model itself does that.
  • The answer for the forgotten preference should name something the application stores and supplies.

Key Takeaways

  • Jagged intelligence means an AI system can be strong on one task and weak on an adjacent one, so you cannot reliably infer quality on neighboring inputs from a single good result.
  • Anterograde amnesia means the system does not learn from one session to the next, so continuity must be engineered in the application layer.
  • The wrapper around the model is where state is stored, retrieved, and supplied, and where failure modes are accommodated.
  • Treating a failure as a bug tends to spend effort in the wrong layer, while treating it as a fact of the substrate and designing around it is the route the source identifies to shipping.