Here's the thing that pulled me in: classical machine learning is, underneath almost everything, kernels wearing different costumes. And once you see that, quantum kernels stop looking like magic and start looking like a very specific, very narrow bet.

Classical ML never really left the dot product

Start simple. A dot product between two vectors tells you how aligned they are — that's the oldest similarity measure there is. SVMs took that idea and got smarter: instead of comparing raw vectors, they compare vectors after mapping them into some richer, higher-dimensional space, using what's called the kernel trick. You never actually build that high-dimensional space — you just compute a kernel function k(x, z) that behaves like a dot product inside it. That's the whole trick.

Then transformers came along, and I think people miss that attention is doing the same thing, just learned instead of hand-picked. A query vector and a key vector get dot-producted, softmaxed, and used to weight values — that's a kernel computation repeated at every layer, over every token, with the feature map (the Q/K projection matrices) trained instead of fixed like an RBF kernel would be. GPT and Claude aren't a departure from kernel methods. They're kernel methods stacked twenty layers deep with the similarity function learned end to end.

So where does quantum come in

A quantum kernel does the exact same job — measure similarity — but the "richer space" is a quantum Hilbert space instead of a hand-designed feature space. You take a classical feature vector, run it through a parameterized quantum circuit (the feature map), and it lands as a quantum state. Similarity between two data points becomes the overlap between their two quantum states, and you get that overlap by literally preparing one state, un-preparing it with the inverse of the other circuit, and checking how often you land back at all-zeros. Do that a few thousand times (shots), count how often you hit zero, and that frequency is your kernel value. Qiskit's Sampler primitive is what actually gives you those raw measurement outcomes — this is a sampling problem, not an expectation-value problem, which took me a minute to get straight since Qiskit also has an Estimator for a different class of question entirely.

Correcting myself: it's not "better data," it's a smarter similarity matrix

Going into this, I'd have told you quantum kernels feed "better data" into a classical model. That's not quite right, and saying it out loud made me catch it. What the classical model actually receives is a precomputed kernel matrix — a grid of pairwise similarity scores — and it trains an ordinary SVM on top of that matrix exactly like it would on an RBF kernel matrix. The quantum part never touches the model's weights or its optimizer. It only changes what "similar" means before the classical machinery ever starts.

The honest state of the science

IBM's 2021 Nature Physics result, from Yunchao Liu, Srinivasan Arunachalam, and Kristan Temme, is the real anchor here: they built a classification problem based on the discrete logarithm problem and proved no classical algorithm can beat random guessing on it in polynomial time, while a quantum kernel solves it cleanly. That's a genuine, rigorous, end-to-end result — not a toy. But it's also the exception that proves the rule. A widely cited 2026 quantum-industry outlook flatly calls quantum ML "one of the most hyped quantum applications of the 2018–2022 era" and "one of the most thoroughly deflated," pointing to a string of dequantization results where classical algorithms caught up to supposed quantum speedups once someone looked closely enough.

I'm not deep enough into the encoding schemes yet to have opinions worth defending on which feature maps are worth building. That's next. But I no longer think of quantum kernels as a better ML model — I think of them as a different lens for measuring similarity, one that's provably powerful on a handful of exotic, structured problems and unproven everywhere else.

That's the part worth remembering: quantum kernels don't replace your model, they replace your notion of "similar." Whether that new notion is worth the qubits is still, mostly, an open question — and that's exactly why it's worth prototyping instead of just reading about.

I rebuilt the entire pipeline from scratch, on my own proxy clusters, ending on a real IBM quantum chip. Full interactive breakdown, every phase, every equation, every job ID, is here: FLiBe Fusion Blanket Chemistry — full interactive lab notebook. This post is the narrative version of that notebook.

Why fusion energy has a tritium problem

Fusion reactors that use the deuterium-tritium reaction need a steady supply of tritium to keep running. The problem is that tritium barely exists in nature — most of what's on Earth was made artificially, and a working fusion plant has to breed its own. The proposed solution is a "blanket" of molten salt, FLiBe (a mixture of lithium fluoride and beryllium fluoride), wrapped around the plasma. Neutrons thrown off by the fusion reaction hit lithium-6 atoms in the salt and split them into helium and tritium. That much is settled chemistry.

What's not settled is the second half: getting the tritium back out. Whether tritium stays chemically locked inside the salt or is recoverable depends on subtle electron-level binding chemistry — and that chemistry involves tightly correlated electrons in a hot, ionic, constantly shifting liquid, which is exactly the kind of system classical density functional theory struggles to get right. This is a real bottleneck standing between where fusion energy is today and a commercially viable reactor, and it's explicitly named as a target of the U.S. Department of Energy's Genesis Mission, which is trying to unify supercomputing, AI, and quantum computing across DOE's 17 national labs to speed up exactly this kind of materials discovery.

What the original team actually computed

It's worth being precise here, because it's easy to over-read a headline like "quantum computer models fusion fuel." The ORNL/Cleveland Clinic/IBM team did not simulate a reactor. They took nine frozen molecular snapshots of small FLiBe clusters — a technique called quantum-centric supercomputing, the same general family of methods IBM and Cleveland Clinic have used to model 12,635-atom proteins — and computed the electronic energy of each cluster twice: once with a tritium atom attached, once without. The difference between those two numbers is the binding energy, and its sign and size tell you whether tritium wants to stay in the salt or leave it.

Cleveland Clinic's presence on a fusion-energy paper looks strange at first glance, until you know their quantum computing partnership with IBM already exists for large-scale biomedical simulation — the same wave function embedding and sample-based quantum diagonalization techniques transfer directly from protein chemistry to molten salt chemistry. It's a methods collaboration, not a fusion lab pivoting into medicine.

Rebuilding it: nine salt clusters, twenty-seven structures

I couldn't use the original team's exact AIMD-generated geometries, so I built chemically faithful proxy clusters instead: nine FLiBe conformations, 21–23 atoms each, in three versions per conformation — the bare anion, the anion with tritium attached, and a check structure — giving 27 total structures. Everything downstream traces back to one equation:

E_bind = E(FLiBeT⁻) − E(FLiBeF⁻)

Tritium is defined as leaving the salt as a bare T⁺ ion with zero electronic energy, matching the paper's convention. A strongly negative E_bind means tritium is energetically comfortable staying put; understanding exactly how negative, and why, is the whole point of the calculation.

The physics underneath: from Schrödinger's equation to qubits

Electrons aren't little balls sitting at fixed points — they're wave-like probability distributions, and the rulebook governing how they behave is the Schrödinger equation, Hψ = Eψ. Solving it exactly for anything bigger than a hydrogen atom is intractable, because electrons don't just respond to the nuclei around them, they also actively avoid each other — a subtle effect called electron correlation that mean-field methods systematically underestimate. FLiBe is an unpleasant test case for this: polarizable fluoride ions, strongly ionic Be–F bonds, and mixed ionic-covalent character all at once.

To make this computable at all, chemists use second quantization: instead of tracking exact electron positions, you track which orbital "seats" are occupied, using creation and annihilation operators. The Hamiltonian becomes a sum of one-electron terms (kinetic energy plus nuclear attraction) and two-electron terms (electron-electron repulsion), both computed directly from the molecule's geometry using a program called PySCF. Map each spatial orbital to two qubits — one for spin-up, one for spin-down — via the Jordan-Wigner transformation, and you've turned a chemistry problem into something a quantum computer can, in principle, represent. The paper's largest single fragment needed 33 orbitals, which is 66 qubits.

I ran RHF (restricted Hartree-Fock) mean-field calculations on all 27 clusters, in the same 6-31+G(d) basis set the original paper used — a dictionary of Gaussian orbital shapes, with extra "diffuse" functions (the +) that matter specifically because fluoride ions are soft and spread out, and polarization functions (the d) that let orbitals distort away from perfect spherical symmetry. All 27 converged cleanly.

Cutting the molecule without losing the chemistry

Here's the part that makes this tractable at all: you never try to solve the whole 21-23 atom cluster as one giant quantum problem. You cut it into fragments, one per atom, using a technique called Embedded Wave Function theory (EWF). Each atom gets localized orbitals via intrinsic atomic orbitals (IAO), a "bath" of neighboring orbital character via a DMET Schmidt decomposition, and then an MP2-based bath expansion that pulls in just enough extra orbital space to keep the fragment chemically accurate. The output is a small, self-contained Hamiltonian per fragment, sized by its active space, M.

Not every fragment is the same size. Lithium and beryllium fragments stayed small, M≈8-15. Fluoride-centered fragments, because fluorine's lone pairs are so polarizable and mix heavily with beryllium's orbitals, ballooned to M≈27-33. This is where a simple rule decides the whole pipeline's shape: fragments with M < 13 get solved exactly, classically, with full configuration interaction (FCI) — the gold-standard, no-compromises answer. Fragments with M ≥ 13 are too large for classical exact diagonalization to handle cheaply, so they go to the quantum path instead.

Where quantum actually enters: LUCJ and sample-based quantum diagonalization

The quantum method here is not VQE, and that distinction matters. Instead, each large fragment gets a Local Unitary Cluster Jastrow (LUCJ) circuit — a fixed-structure ansatz, seeded directly from a classical CCSD calculation's T1 and T2 amplitudes, run at circuit depth n_reps=1. That circuit is sampled thousands of times, either on a noiseless Aer simulator or on real IBM hardware, producing a long list of measured electron-configuration bitstrings.

From there, sample-based quantum diagonalization (SQD) takes over, entirely classically: it recovers the physically valid electron configurations from the noisy sample, builds a compact configuration-interaction Hamiltonian restricted to just those configurations, and diagonalizes it on a normal computer. The "ext" in ext-SQD means the subspace gets extended afterward with single excitations and rediagonalized, squeezing out a bit more accuracy. The quantum processor's only job is generating a good list of candidate configurations to search over — the actual energy comes from classical linear algebra. I solved 108 fragments this way across the full 27-structure set.

The finding that actually matters

Here's the headline result, and it's a slightly uncomfortable one if you were hoping quantum hardware would be the star: comparing ext-SQD against exact classical FCI on the fragments small enough to check both ways, the two methods agreed to within roughly 0.7 kcal/mol, and to about 0.3 kcal/mol mean absolute deviation on conformational energy differences specifically. That's excellent agreement — the quantum-assisted solver is doing its job correctly.

But compare the embedded-fragment approach as a whole against uncut, full-molecule reference methods, and the gap jumps to around 110 kcal/mol on binding energy. The bottleneck isn't the quantum computer. It's how you slice the molecule into fragments in the first place. I found the same qualitative pattern in my own recreation, and it's worth sitting with: the most expensive, most hyped part of this pipeline — the quantum circuit — was never the weak link. The unglamorous classical embedding step was.

My numbers against the published band

The mean landed inside the published range and the direction matched exactly, which is the qualitative result that actually matters. It is not a quantitative table match — my proxy geometries weren't the paper's exact AIMD-sampled structures, so the specific numbers were never going to line up atom-for-atom.

Real IBM hardware, twice

Everything above can run on a simulator. I wanted the real thing too, and it took two attempts.

The first job went to ibm_marrakesh — job d9kuplqbr2fc73e7u0g0 — and sat in queue for about 30 minutes before hitting my own 1,800-second queue ceiling and getting cancelled. Zero actual QPU time was burned; it never got past waiting in line. The lesson was blunt: the backend with the least-pending queue beats the backend with the biggest marketing qubit count, every time.

The second attempt went to ibm_fez instead. A 26-qubit LUCJ circuit (the M=13 fragment), transpiled to a depth of 752 with 1,170 two-qubit gates, 4,096 shots, submitted through Qiskit Runtime's SamplerV2. Total wall time 64.3 seconds, with 38.2 seconds actually in the RUNNING state — well inside my 120-second budget, kill switch never triggered. The fragment energy came back at −52.126 Hartree on hardware versus −52.117 Hartree in noiseless simulation, a difference of about 5.6 kcal/mol. That's real hardware noise, and it's a small, honest gap — nowhere near enough to change the qualitative conclusion, but a useful reminder that noiseless simulation and a real chip are not interchangeable numbers.

The honest scoreboard

What this actually teaches

I didn't discover new fusion chemistry, and I didn't run the paper's full computational campaign — nobody should read a solo recreation as replacing peer-reviewed national-lab work. What I did confirm, end to end, on my own infrastructure, is that this exact pipeline — Hartree-Fock, embedded wave function fragmentation, a classical FCI/CCSD ladder, LUCJ circuits, sample-based quantum diagonalization, and a real IBM chip at the end — runs correctly and reproduces the paper's central, slightly humbling lesson: in quantum-centric chemistry, right now, the embedding decision matters more than the qubit count. Getting the cut right is the hard part. The quantum computer is just very good at the part that's left over once you've cut correctly.

Every phase, every fragment Hamiltonian, every job ID, and the seven-episode "Salt Keepers" learning story I wrote alongside it are in the full notebook: FLiBe Fusion Blanket Chemistry — full interactive lab notebook.

Direction one: AI is what's actually keeping quantum hardware alive

This is the direction people expect, but the mechanism isn't what most assume. AI isn't making quantum computers faster in the way a better GPU makes a model faster. It's making them survive long enough to finish a calculation at all.

Qubits decohere — they lose their information to noise almost as fast as you create it — which is why error correction is the whole ballgame right now, not a side detail. Google Quantum AI recently published a machine-learning approach, led by researcher Volodymyr Sivak, that continuously recalibrates a quantum processor mid-computation instead of pausing to do it.

IBM has gone a step further and used LLMs, through a workflow called OpenEvolve, to search through thousands of candidate error-correction code designs and surface ones humans hadn't tried — including one requiring far fewer physical qubits than the previous best in its class. Neither of these is AI helping quantum compute faster. It's AI helping quantum computers stay coherent long enough to compute at all.

Direction two: what quantum actually gives AI, and it's not speed

Here's where the expected story breaks down. The obvious assumption is that quantum hardware will someday train AI models faster or run inference better. That's not the real mechanism, and I think it's worth being precise about why.

Start with what AI is actually doing when it does scientific work. When a model predicts how a material behaves, how a protein folds, or how a climate system evolves, it isn't solving the underlying physics from scratch — it's acting as a surrogate.

A stand-in that imitates a full simulation, at a fraction of the cost, because it's learned the mapping between a system's structure and its behavior from examples it's already seen. That's why these models are so fast: they replace a simulation that would take days with a prediction that takes minutes, across materials discovery, drug design, climate modeling.

But a model built this way is only as good as what it learned from. And in the hardest cases — strongly correlated systems, the ones where electron interactions genuinely matter — the training data itself usually comes from classical approximations that are incomplete by construction. The model faithfully learns the approximation. It also faithfully inherits its blind spots.

This is where quantum enters, and I want to flag this as a forecast, not a settled result. Chi Chen of IonQ and Matthias Troyer of Microsoft have proposed, in an IEEE Spectrum essay, that a quantum computer's most valuable near-term job may not be answering scientific questions directly.

It may be generating small amounts of extremely accurate ground-truth data — data that's prohibitively expensive to compute classically — specifically in the regimes where the classical approximation fails. Train the classical AI model on that quantum-generated data, and in their framing, you get the accuracy quantum can deliver, at the speed AI can deliver it.

Troyer has described the near-term goal elsewhere as "teaching quantum physics to AI" — using quantum hardware to refine models that are already pretrained classically, rather than replacing classical computation outright.

The two directions converge on the same target

Both fields are ultimately aimed at the same thing: describing nature accurately enough to act on it. They're just approaching from opposite ends. AI learns the patterns. Quantum supplies the ground truth those patterns are learned from.

The likely endpoint isn't "quantum or AI." It's quantum teaching AI — one supplying the accuracy, the other supplying the reach and the speed. Where exactly the line falls between what AI can already approximate well enough, and what genuinely needs quantum-grade data, is still being drawn in real time. I don't think anyone — including the people proposing this — knows precisely where that line sits yet.

That's not a hedge. It's the actual research frontier right now, and it's a more interesting place to be building than either "quantum is everything" or "quantum is nothing" gives it credit for.

What's actually happening is more interesting than either the hype or the dismissal gives it credit for. So let's walk through it — not "quantum will change everything," and not "quantum is a decade-away curiosity," but what teams are literally doing on Monday mornings right now.

The workflow nobody talks about: building the team before the machine is ready

JPMorgan Chase runs the largest quantum effort of any US bank through a unit called FLARE — the Future Lab for Applied Research and Engineering. What's notable isn't the qubit count. It's the sequencing.

Marco Pistoia, who leads the group, has said the point of investing now is becoming "quantum-ready," not quantum-productive. That's a real distinction, and it's the first thing I want to sit with: in this field, the workflow often precedes the payoff by years.

JPMorgan has poured $100 million into Quantinuum, built an internal bench of over fifty physicists and mathematicians, and published peer-reviewed work on portfolio optimization and Monte Carlo acceleration — all while publicly acknowledging that an internal study found limited practical advantage so far.

That combination — real budget, real publications, honest limits — is what a mature enterprise program looks like. Compare that to Goldman Sachs, which has taken a visibly smaller, slower path on the same technology. Two banks, same tools available, very different bets on timing.

The actual day-to-day work in these teams looks like: pick a narrow, well-defined subproblem (constrained portfolio optimization, say), formulate it as a quantum circuit using a toolkit like Qiskit, run it on rented time on a trapped-ion machine — JPMorgan has used Quantinuum's H1 and H2 systems — and compare the output against a classical baseline. Most weeks, classical wins. The team publishes anyway, because the point is building institutional muscle memory for the day the comparison flips.

The workflow in pharma: quantum as one stage in a much longer pipeline

Drug discovery gives you a cleaner picture of the actual research process. IBM and Cleveland Clinic recently ran a variational quantum eigensolver — a hybrid algorithm that splits work between a quantum processor and classical density functional theory — on a 303-atom mini-protein, using IBM's 156-qubit Heron chip. That's a genuinely new capability: the first protein-scale quantum chemistry simulation of its kind.

The workflow there is: classical methods handle the bulk of the molecule, and the quantum processor gets called in specifically for the electron interactions that classical approximations handle badly. Boehringer Ingelheim runs a similar partnership with Google Quantum AI.

AstraZeneca has reported a 20x speedup on a specific drug-discovery workflow segment using IonQ hardware through AWS — not an end-to-end simulation, but one stage of a much longer pipeline getting meaningfully faster.

What I actually tell you to take away

If there's one pattern across finance, pharma, logistics, and materials science, it's this: nobody is replacing their classical stack. They're identifying the one subroutine in an existing workflow where classical methods hit a wall — a combinatorial explosion, an electron correlation problem, a search space too large to brute-force — and inserting a quantum step there, then handing the result back to classical infrastructure. Hybrid isn't a compromise; right now, it's the entire architecture.

I'll admit I used to find this unsatisfying — I wanted the clean story where quantum computers just start winning outright. It took me longer than I'd like to accept that the actual value right now is optionality: teams that built this muscle in 2023 and 2024 are the ones positioned to move fast whenever the hardware crosses the threshold. The teams that waited for proof before starting are, by definition, starting later. In a field where the talent takes years to build and the useful hardware window is still genuinely uncertain, being early and wrong for a while is cheaper than being right but late.

Professional work is even more obviously this. A support engineer's whole job is watch-the-queue, triage, resolve, watch again. A trader's whole job is watch-the-price, evaluate against a thesis, act or wait, watch again. A sales rep's pipeline is a loop with a memory — you don't cold-call the same lead the same way twice, because the last call changed what you know. None of this is new. What's new is that we finally have a name for building the same pattern into software, and for a few years, most of us building AI agents didn't have it.

The loop I built before it had a name

A while back I was building an agentic system for analysis and trading in capital markets — something that could read a thesis, watch a name, and act on it without me babysitting every tick. The naive version was obvious and useless: poll the price every few minutes and ask a model "anything interesting here?" That burns tokens and produces noise, not judgment.

What actually worked was inverting it. Instead of the agent watching the market, I had the system set a price alert with the reasoning attached — not just "notify me at $142," but the actual context: why that level mattered, what thesis it would confirm or break, what to check when it fired. The alert sat dormant, cheap, doing nothing. When price crossed the line, that stored context triggered the agent, and the agent woke up already knowing why it was awake. It didn't have to re-derive the situation from scratch — it picked up the loop mid-cycle, with memory.

At the time there was no term for this. I wasn't "designing a loop," I was just trying to stop paying for an agent to stare at a chart. A decent amount of the actual work was mechanical — weighting which price zones mattered more than others, deciding what counted as a "trigger" worth waking the agent for versus noise to ignore, a fair bit of scoring logic sitting quietly behind what looked like a simple alert.

Then, this June, it got a name

On June 7, 2026, Peter Steinberger — the developer behind OpenClaw — posted that developers should stop prompting coding agents by hand and instead design the loops that prompt those agents, a post that reportedly hit around 6.5 million views within days. Boris Cherny, who leads Claude Code at Anthropic, had already been saying something similar on stage, describing his own job as writing loops that prompt Claude rather than prompting it directly. Days later, Google's Addy Osmani turned the idea into something teachable, and the term "loop engineering" stuck.

The definition that emerged matches what I'd stumbled into without knowing it: a loop is an agent that acts, observes what actually happened — a test result, an error, a market move — and adjusts, repeating until the work is accepted or blocked, rather than a human re-prompting it at every step. The best writeups converge on the same non-negotiables: a specific goal with a testable stopping condition, tools the agent can actually use, context management so it doesn't drown in its own history, and explicit exits so it doesn't run forever. My price-alert-with-context setup was, unknowingly, a crude version of exactly that: goal (react to this level), trigger (price crosses it), memory (the thesis attached to the alert), stop condition (the trade decision itself).

Why this is the real unlock for autonomy

Prompting is you doing the thinking, one exchange at a time. A loop is you doing the thinking once, well, and then trusting the system to re-apply it every time the world changes. That's a small mechanical shift with a large consequence — it's the difference between an assistant you operate and a system that operates itself inside boundaries you set. Every genuinely autonomous agent I've seen actually hold up under real conditions was a loop with good judgment baked into its stopping conditions, not a bigger model with a longer prompt.

The dream isn't agents that respond faster. It's systems that keep watching, keep deciding, keep remembering why — long after you've stopped thinking about the problem yourself.

Real creativity — in humans and, increasingly, in agents — comes from two things: pattern recognition across well-structured memory, and metacognition that continuously refines how the system thinks. Neither is easy to engineer. But both are buildable.

Memory Architecture Is the Foundation for Pattern Recognition

The first mistake I made when building agentic systems was treating memory as a retrieval problem. Something happens, you store it. Something gets asked, you retrieve the closest match. The problem is that flat retrieval doesn't produce insight. It produces recall.

The research is catching up to this intuition. Graph-based memory has emerged as the real frontier in 2025–2026, and the reason is structural: it encodes relationships between memory elements, not just the elements themselves. You can traverse from a concept to a causal chain to a historical analogy, following edges rather than scanning similarity scores. That traversal is what produces the kind of thinking humans associate with depth.

What this looks like in practice: instead of storing "Agent flagged anomaly on trade X," you store that event as a node connected to the market condition that preceded it, the decision the agent made, the outcome that followed, and every similar event in the past. Now when a pattern emerges, the agent isn't searching for the closest document — it's walking a graph to find structural recurrence.

Frameworks like Mem0 (which released graph memory support and a dual-store architecture combining vector and knowledge graph in late 2025) and Zep (temporal knowledge graph for agent memory) are building exactly this. The multi-hop reasoning gains are measurable. When tested on temporal queries and multi-hop reasoning tasks, graph-based retrieval showed improvements of 20+ points over flat retrieval in recent benchmarks.

The implication for how you build: your memory design should be the first architecture decision, not the last. If you're starting with a vector store and asking "what should we index?" you're already behind. The questions are: what entities matter, what relationships connect them, and what traversal logic lets the agent discover what it doesn't know to look for?

Metacognition: The Loop That Doesn't Stop at Execution

The second piece is trickier, and I'm more uncertain about it than the memory stuff — so take this as a working model rather than settled engineering.

Metacognition in AI agents is essentially loop engineering. It's not enough to have the agent act and then evaluate. The really interesting systems run a second loop that observes the first one — watching how the agent used tools, what chains of reasoning it followed, where it got confused or inefficient — and then uses that observation to update behavior.

The closest real-world analog is dreaming. Humans consolidate learning, process failures, and form generalizations during sleep. In agentic AI, this has moved from metaphor to actual feature. Anthropic launched Dreaming for Claude Managed Agents in May 2026 — agents review their own past sessions during idle time, extract patterns from what worked and what didn't, and write memory notes that improve future performance without retraining. Harvey, the legal AI platform, reported a 6x improvement in task completion after enabling it. OpenAI followed with Dreaming V3 for ChatGPT on June 4, 2026, framing it as autonomous memory synthesis that replaces static saved memories with a self-updating model of the user.

The research mirrors this. The MARS framework (Metacognitive Agent Reflective Self-improvement) shows how agents can improve by abstracting normative rules from failures and deriving step-by-step strategies from successes — then synthesizing those into updated instructions. The key insight is that this loop doesn't require continuous online feedback or human intervention for every update. It can run asynchronously, batch-observing many sessions before surfacing a refinement. Human-in-the-loop approval gates can be added for higher-risk instruction changes.

What this means architecturally: build execution loops and observation loops as separate systems. The execution loop handles tasks. The observation loop watches the execution loop, classifies behavior patterns, and queues instruction updates for review. You're not building one agent — you're building an agent and the thing that watches and improves the agent.

The Models That Can Actually Do This

None of this works without a model that can reason deeply across multiple steps. Pattern recognition in a graph requires following chains that aren't obvious at retrieval time. Metacognitive loops require the model to produce reliable self-assessments, not hallucinated ones.

The landscape for this is better than it's ever been, and more competitive than most people realize. Claude (Sonnet and Opus) still leads on long-horizon reliability and nuanced instruction following. But the open-weight frontier has compressed dramatically. In June 2026, GLM 5.2 from Zhipu AI tops the Intelligence Index at 51 among open-weight models; Kimi K2.7 Code from Moonshot leads on agentic MCP tool-use in long-horizon tasks; DeepSeek V4 Pro leads on raw SWE benchmarks and has reset the cost floor. The point isn't which model to pick — it's that the base reasoning capability to run genuine metacognitive loops is now available at price points that weren't viable a year ago.

What This Doesn't Mean

I want to be honest about where this trajectory ends. Agents with structured graph memory and real metacognitive loops will outperform humans at well-defined, knowledge-intensive tasks. They already do in narrow domains. But the particular kind of creativity that produces genuinely new insight — a leap across domains that no training distribution would suggest, or a re-framing so unexpected it changes what questions are even worth asking — that's still rare in AI systems. And I'm not sure how close we are to it.

The architecture I've described makes agents smarter within the space of what they've experienced and observed. Real human creativity often starts outside that space entirely. That gap is worth respecting — both because it's honest, and because it points to where the interesting hard problems are.

The agents worth building right now are the ones that think well, not just the ones that respond quickly. Memory that's connected, not indexed. Loops that observe and improve, not just execute and stop.

The ceiling is higher than most current systems suggest. Build toward it.

Everything else — reasoning, judgment, instinct — is built on top of those two. AI agents are no different. We talk endlessly about the creativity side: better prompts, better reasoning chains, better tool use. Memory gets treated like plumbing. It isn't. It's half the job.

An agent without memory isn't an agent. It's a very articulate autocomplete that forgets you exist the moment the session ends. Real agentic behavior — the kind that gets better over time, that remembers what worked last quarter — needs memory architecture, not just a longer context window. Picking the wrong one is one of the most expensive mistakes you can make early, because it's painful to rip out later.

There isn't one right answer. There are four real patterns, each the right call for a different shape of problem.

Chat History and Agent State

This is the baseline — short-term working memory. The running conversation, current task state, maybe a scratchpad the agent writes to mid-execution. Cheap, fast, and what every agent has by default whether you designed for it or not.

Use it for: single-session tasks where continuity beyond "right now" doesn't matter. A coding agent mid-task, a support bot resolving one ticket.

Don't use it for: anything that needs to persist. The moment the agent needs to remember a preference from three weeks ago, working memory falls apart. Long-context models with large windows at flat pricing have made "just stuff more into context" cheaper than people assume for smaller agents — but that's a patch, not an architecture. It still resets.

RAG and Vector Stores

This is the default most teams reach for, and for good reason — embed your documents, retrieve by semantic similarity, stuff the top results into context. It's mature, well-tooled, and good at one thing in particular: surfacing the most similar piece of information to a query.

Use it for: large, relatively flat document corpora where similarity search is genuinely what you need — FAQ retrieval, support docs, anything where "find me the chunk that sounds like this question" is the actual task.

Don't use it for: anything requiring multi-hop reasoning or relationship-tracing. A vector store hands back a ranked list of similar chunks. It can't tell you that customer X uses product Y, which had an incident last month similar to a case from a different customer entirely. That's a structural limitation — flat similarity search can't traverse relationships it was never asked to encode.

Knowledge Graphs (Neo4j and friends)

This is the architecture for when relationships are the data. Entities, edges, multi-hop traversal — an agent can walk from a fact to a related fact, which a vector store fundamentally cannot do. The more advanced versions now treat time as a first-class dimension — facts get versioned, and the agent can reason about what was true versus what's true now.

Use it for: domains that are genuinely relational — fraud detection, compliance webs, anything where the value is in the connections between entities, not just the entities themselves.

Don't use it for: everything, which is the trap I almost fell into. Knowledge graphs are powerful and also heavy — schema design, entity extraction, ongoing graph maintenance. If your problem doesn't actually need multi-hop relational reasoning, you're paying graph-database tax for vector-store value.

Wiki-Style Document Memory

This is the one I don't see written about enough, probably because it's less novel than a graph and less default than RAG — but it's been the right answer for a system I recently built.

I was building a financial research and analysis system where the agent's memory is, functionally, a wiki: structured notes, reports, and insights, each its own document. The pattern is two-stage retrieval. First, the agent uses indexing and metadata filters to retrieve a list of candidate notes — titles, tags, summaries — without pulling full content. Then, based on that list, it retrieves the full content of only the notes actually relevant to the task.

I almost built this as a knowledge graph first. It felt like the "correct" engineering answer. It took me longer than I'd like to admit to realize research and analysis isn't fundamentally about traversing relationships between entities — it's about retrieving the right documents and reasoning over them as wholes. A graph would've fragmented exactly what made the notes useful: the analyst's full reasoning, written in one place.

The magic :

The real magic happened when i added neo4j style edges / connections between wiki style documents. The agents have become smarter with the ability to traverse through notes & documents connected with relationships and relationship strengths.

Use it for: structured analytical work where documents are the natural unit of knowledge — research notes, investment theses, audit reports, anything a human analyst would also want to read whole, not as a fragmented graph node. It's also the most enterprise-friendly of the four: a wiki of notes is something a finance or research team can browse and manage directly, outside the agent entirely. That matters — memory only an engineer can inspect is memory the rest of the org doesn't trust.

Don't use it for: high-volume, low-structure data where indexing every chunk as a discrete "note" creates more overhead than value, or for problems that are genuinely relational rather than document-centric.

Choosing the memory architecture that fits your agent's actual reasoning pattern — not the one that sounds most sophisticated on a slide — is, in my estimate, fully half the job of building an intelligent agent. The other half is creativity: reasoning, prompting, judgment under ambiguity. I'll get into that next week.

Get memory wrong and no amount of prompt engineering saves you. Get it right and the agent starts looking less like a clever autocomplete and more like something that's actually been paying attention.

And then your cloud bill shows up.

I've been there. And honestly, watching companies like Microsoft and Uber publicly wrestle with runaway AI infrastructure costs was a wake-up call for me too. These aren't small teams fumbling around — these are organizations with some of the best AI engineers on the planet. And they're still figuring out how to make agentic systems not just work, but work efficiently.

So here's what I've personally been learning and unlearning.

1. Match the Model to the Job

This one took me longer to internalize than I'd like to admit: you don't need Claude or GPT-4 for every single step in your pipeline.

A well-prompted DeepSeek or a capable flash-class model can get you 99% of the way there on tasks like classification, extraction, structured formatting, or simple reasoning — at a fraction of the cost. The moment I stopped treating LLM selection as a one-size-fits-all decision and started matching model capability to task complexity, costs dropped noticeably.

And here's the thing — as models have gotten better, I think many of us have quietly let our prompt engineering get lazier. That's a mistake. Strong prompting still matters enormously, especially when you're trying to squeeze real performance out of a lighter model. Don't outsource your thinking to the most expensive model available when a well-crafted prompt to a cheaper one does the job.

2. Context Engineering is Everything

I've seen agents fail not because of bad models or broken logic — but because they were drowning in noise.

Dumping your entire knowledge base into context is not engineering, it's hoping. What you actually want is a clean, well-structured knowledge layer where the agent can ask for exactly what it needs — and receive back only what it needs, nothing more.

This applies to tools too. Every tool in your agentic system should be designed with surgical precision: clear inputs, scoped outputs, no data dumps. When an agent calls a tool and gets back a wall of loosely structured JSON, it has to spend tokens just making sense of it. That's waste you're paying for.

Good context engineering is the difference between an agent that reasons cleanly and one that hallucinates under the weight of its own context window.

3. Not Everything Needs an Agent

This one is hard to say out loud in certain circles, but: most workflows don't need a full agent.

Agents are expensive by design. They carry instructions to handle many scenarios, they manage tools, they maintain memory, they loop until they reach a goal. All of that burns tokens — on every single run.

Before reaching for an agent, ask yourself: can I solve this with a deterministic workflow, a few LLM calls with structured output, and some conditional logic? More often than not, the answer is yes. A clean workflow with targeted LLM calls — one to extract, one to transform, one to summarize — is faster, cheaper, more debuggable, and honestly, easier to trust in production.

Build agents where genuine autonomy and adaptive reasoning are required. Not because it sounds impressive on a slide.

4. LLMs Are a Tool, Not the Default

This is the underlying principle behind all of the above.

Just because a language model is accessible doesn't mean it's always the right tool. Regex handles pattern matching better than an LLM. A database query retrieves structured data more reliably than prompting a model to "find" something. Deterministic logic is more trustworthy for branching decisions than an LLM-reasoned if/else.

The best AI systems I've seen aren't the ones that use AI the most — they're the ones that use AI precisely, reserving it for the steps where natural language understanding, generation, or fuzzy reasoning actually adds something that code alone can't.

5. Build Small, Focused Sub-Agents — Then Orchestrate Them Well

Here's something I've started doing that changed how my systems perform and what they cost: instead of building one big general-purpose agent with a massive system prompt, a long list of tools, and instructions to handle everything — I build small, purpose-built sub-agents, each designed for one specific outcome.

Each sub-agent gets its own tightly engineered prompt, only the tools it actually needs, and clear input/output contracts. A research sub-agent that only knows how to search and summarize. A data extraction sub-agent that only reads and structures. An action sub-agent that only writes or calls APIs. Focused. Contained. Predictable.

Then you build a clean orchestration layer that routes work to the right sub-agent based on what's needed at each step. This is where the real gains come from — the orchestrator doesn't need to be expensive either, it just needs to be smart about routing. Fewer tokens wasted on irrelevant instructions, fewer hallucinations from overloaded context, better debuggability because each unit has a single responsibility.

For production-grade systems, I've been using Mastra — an open-source TypeScript framework that makes this pattern genuinely easy to build. It handles agent orchestration, tool definitions, memory, and step-based workflows with a clean developer experience that doesn't get in your way. It's solid, it scales, and it's built for the real world — not just demos.

The mental model shift is simple: stop thinking "one smart agent that handles everything" and start thinking "a well-designed team of focused agents, coordinated by a clear orchestration layer." That's how you build systems that are both powerful and efficient.

The Real Goal

We're not here to build AI agents. We're here to build systems that create real value by automating real problems.

Sometimes that's a fully autonomous multi-agent system. Often, it's a workflow with two LLM calls and a well-placed conditional. The measure of good engineering isn't how much AI you used — it's how much value you delivered, at what cost, with how much reliability.

That's the shift I keep coming back to. Build for outcomes, not optics.

Intro... 🙋‍♂️

Remember that, this is about the initial version of NFT.JS and to use NFT.JS you need to use the NFT.JS 2.0. You can checkout it here

If you're a web3 developer, you will definitely know what NFTs are and might have also implemented them somewhere in your previous projects or Dapps right?

Usually, implementing NFTs in the Dapps includes the work of creating an ERC721 contract using solidity, testing them and deploying to the network using Truffle & Ganache or Remix IDE and then interacting with the contract from the Dapps using web3js.

Not done yet! You need to use IPFS to store metadata as well as files in the metadata like images, videos or other media content.

Have you ever thought of using a single library that can perform all these tasks! NFT.JS has taken birth here :)

Let's move on to the detailed talk on NFT.JS

Before moving on, I have a small request. If you found NFT.JS interesting and useful please consider upvoting it on Product Hunt

Visit : NFT.JS

What's NFT.JS... ‼️

Long story short, NFT.JS is a Javascript library that does all the above discussed tasks to implement NFTs in the Dapps.

Building a NFT marketplace ? Developing a Decentralized social platform or any other Dapps that needs to implement NFTs ? If "yes", using NFT.JS is a cool thing that you can do.

Using NFT.JS, you can deploy a ERC721 contract that can perform all the required functions without writing a single line of Solidity. You can easily interact with the contract by calling the functions and sending transactions to the contract with just 1-2 lines of NFT.JS and it also removes the usage of IPFS.

You can simply provide the input file into the metadata object and NFT.JS uploads all the files provided in the metadata to IPFS and lastly uploads the metadata.json file to IPFS and mints the NFT.

Have you heard of lazyMinting ? NFT.JS also provides that cool feature. In lazyMinting, the user can mint a NFT where the token data is stored off-chain(ipfs) to avoid gas fee and in future, if a buyer is ready to buy that NFT, the data moves on-chain by minting the NFT to the buyer. Here the user can get rid of gas-fee which is a big entry barrier.

Planning to build your Opensea ? Don't reinvent the wheel and consider using NFT.JS.

Tech Stack used... 👨‍💻

1. Javascript (programming language of the library)

2. Solidity (to create a ERC721 contract)

3. Web3.JS (to deploy and interact with the contract)

4. Moralis (for RPC nodes and IPFS gateway)

The technologies mentioned above are used to develop NFT.JS

Why use NFT.JS... ❓

The 3 main benefits that you can enjoy using NFT.JS are...

1. Low code development

NFT.JS completely diminishes the usage of Solidity to create smart contracts.

Not only that, using web3.js to interact with a contract also requires 4-5 lines of code right? NFT.JS does that same thing in just 1-2 lines of code.

2. Integrated IPFS

Need to use a 3rd party IPFS node and gateways like Infura, Alchemy? No need, Moralis IPFS gateway is integrated to NFT.JS and doesn't even need to code to use IPFS.

Using Moralis IPFS that is integrated to NFT.JS gives you a cool experience and can handle files that are as large as 1GB and that's the maximum limit.

3. Implement lazyMinting

LazyMinting is a cool experience that you can give your Dapp users. NFT.JS also provides the feature of implementing lazyMinting.

Not only that, getting started with NFT.JS is very simple and implementation & usage is super easy.

Isn't it cool...?

How to NFT.JS ⚙

(deprecated. see NFTJS 2.0 here)

Now let's jump into a deep talk on how to use NFT.JS by exploring its usage and implementations.

Install NFT.JS

The first thing you need to do to get started with NFT.JS is to install it by adding a simple script tag in the <head> section of your index.html file.

<script src="https://nftjs.netlify.app/nft.js" type="text/javascript" />`

Initialize it...

After installing NFT.JS you need to initialize the NFT.JS by providing the ethereum network (mainnet/rinkeby/ropsten...) and the user's wallet address as strings in the following way.

NFTJS.start("rinkeby", accounts[0])

If you want to change the network or user's wallet address in any instance, you can easily do it by calling the same function again with different parameters.

NFTJS.start("ropsten", accounts[1])

Deploying a collection contract

The ERC721 contract is created using Solidity with all the required functions and compiled already. By calling the createCollection function, you can deploy it to the network that you have set in NFTJS.start().

The required parameters are name of the collections as a string, SYMBOL of the collection as a string, publicMintable as string ("true"/"false") and maxSupply as an integer.

publicMintable is a parameter that defines if you would like to allow others (other than owner) to mint NFTs in the collection and Default value is false and it's always false unless you give "true" as the parameter value.

await NFTJS.createCollection(
"Nftify",
"NFY",
"true",
10000
)

After the transaction receipt gives the deployed contractAddress, you can get it by calling a simple function like this.

var address = NFTJS.deployed()

This only gives the address of the collection that is most recently deployed in that web session. If either the page is reloaded or a new contract is deployed, the address of the past contract is gone.

Initiating a collection

Initiating a collection requires the address of that contract and must be deployed to the network that you have provided in the NFTJS.start()

var collection = new NFTJS.collection(address)

Functions of a collection

Now let's see how to interact with a smart contract by sending and calling the data.

1. mintNFT : Minting an NFT requires the metadata object which contains the items like name, description, image and others.

Let's discuss the role of IPFS here. The first thing that the minNFT function does is, it checks if an item in the level 1 items of the object is a file. It uploads all the files to the IPFS and replaces the file values with the file URL. It will take some to complete the whole process.

Note that, if a file input's value is given in metadata and the user doesn't upload a file, the function fails.

After uploading the files in metadata, it uploads the final metadata object to the IPFS and then sends the transaction to the metamask wallet.

await collection.mintNFT({
  name : "king",
  description :  "king of the kingdom",
  image : inputElement.files[0]
})

2. lazyMintAndTransfer : This is a function which is similar to mintNFT but is needed if you want to provide your users a gas free minting experience.

The required parameters are minter, price and metadata. Here, the buyer of the NFT is the user who is calling the function and the minter is the one who minted the NFT off-chain. The price is the amount of ETH the buyer needs to pay the minter.

The metadata of the NFT stored off-chain while minting should be given as the parameter. Dealing with metadata and IPFS is the same as in the mintNFT function.

As soon as the transaction is completed, the NFT data moves on-chain by directly minting it to the buyer and the ETH gets transferred to the minter address.

await collection.lazyMintAndTransfer(
  nft.minter, 
  nft.price,
  nft.metadataObj
)

3. updateNFT : This is a crucial function to update the NFT's metadata. This function requires the ID of the NFT that needs to be updated and the new metadata that needs to replace the old one.

Here, the user must be the owner of the NFT.

Dealing with metadata and IPFS is the same as in the mintNFT function.

await collection.updateNFT(id, {
  name : "king1",
  description :  "king1 of the kingdom1",
  image : inputElement.files[0]
})

4. burnNFT : This function is used to burn or delete the NFT. This function requires the ID of the NFT that has to be minted and the user must be the owner of the NFT.

await collection.burnNFT(id)

5. approve : This function is used to give the transfer approval to the collection contract. This function requires the ID of the NFT that has to be approved and the user must be the owner of the NFT.

await collection.approve(id)

6. setApproveAll : This function allows the user to give or revoke approval on all his NFTs to the collection contract. The parameter that you need to give is a string form of the boolean ("true"/"false").

The default value is "true" and is always the same unless you give a parameter like "false".

await collection.setApprovalForAll(bool)

7. transfer : This function is used when a user wants to transfer his/her NFT to anyone he/she wishes. The required parameters are "to" which is an address to which he/she wants to transfer and the ID of the NFT.

await collection.transfer(to, id)

8. transferFrom : This function is basically a buy function. The required parameters are from, to, price and id. As this transfer is made by the collection contract, the from/owner must give the approval to the contract before calling this function.

Usually, this function should be called by the "to". This function transfers the NFT of the given ID from "from" to the "to" and transfers the ETH of "price" from "to" to the "from". As said, it's a biy function and msg.value must be > 0.

await collection.transferFrom(from, to, price, id)

9. details : This function returns the object that includes the details of the collection like, name, symbol, owner, maxSupply, publucMintable and totalSupply. Here, totalSupply also includes the burned NFTs.

var details = await collection.details()

10. getApproved : This function takes the ID of a NFT and returns the address to which the owner has given approval of that NFT id.

Usually, it returns the address(0) if not approved and returns the address of the collection if approved.

var address = await collection.getApproved(id)

11. isApprovedForAll : This function returns the boolean value. This boolean is equal to the value given in the setApproveAll function. Its default value is false.

var bool = await collection.isApprovedForAll()

12. ownerOf : This function returns the owner's address of the given NFT id.

var owner = await collection.ownerOf(id)

13. balanceOf : This function returns the no.of NFTs holding of the given user's address.

var balance = await collection.balanceOf(address)

Hope you understand how to use NFT.JS to implement NFTs in your projects in a low-code way and save your valuable time & energy.

If you have any doubts, found any bugs or want to give a suggestion or feedback on NFT.JS you can comment down below or can reach out to me on twitter

Limitations... ⛔

The only 2 limitations of NFT.JS are...

1. It only supports Ethereum, not other networks like Polygon and BSC and only the ERC721 standard, not ERC1155.

2. While implementing lazyMinting, you need to store the token data off-chain right ? Unfortunately, NFT.JS doesn't provide the option to store the off-chain data and you need to set up your own space for that.

Future plans... 🔮

As a developer and a problem-solver, the only future plan for NFT.JS is to break the above limitations...

I think it would be great if NFT.JS also supports ERC1155 as well as other networks like Polygon and BSC. Using Polygon or BSC is a great thing to reduce the gas fee.

I also feel that, ETH2.0 can also replace the positions of Solana, Polygon and BSC coz, ETH2.0 is an upgraded version of ETH and uses proof-of-stake which may result in a much lower gas fee than Polygon and BSC.

Final Thoughts... 🙂

I'm so excited and happy that I also completed developing something that can help my fellow devs.

Uhhh.....

Finally, if you are to build something that requires implementation of NFTs please consider using NFT.JS...

Taking a leave for now...👋Bye!