AGI

People talk about AGI as if it were a finish line.

At some point, a model will supposedly become smart enough, cross an invisible threshold, and we will all agree that artificial general intelligence has arrived.

I don’t believe it will happen that way.

The word AGI hides several different ideas. Some people mean a system capable of doing most economically useful work. Some mean a machine that learns like a person. Some mean an autonomous scientist. Some mean a language model that makes fewer mistakes.

Those are not the same target.

The definition I find most useful is more operational: an AGI-like system should be able to pursue unfamiliar goals over time in changing environments, use tools, preserve relevant state, learn from feedback, and recover when its first plan fails.

That definition makes AGI feel less like one model and more like a complete system.

AGI is a systems problem

Current models already have pieces of general intelligence. They can write software, explain unfamiliar topics, analyze images, use tools, and solve problems they have never seen before.

But the model is only one layer.

intelligent system =
    model
  + context
  + retrieval
  + persistent state
  + tools
  + feedback
  + evaluation

The model produces an inference. The rest of the system determines what the model sees, what it is allowed to do, what happened after it acted, and whether it should change its next decision.

Without those layers, a model can be impressive and still be useless for long-running work. It can answer a question about a project without knowing what changed yesterday. It can propose a code fix without running the tests. It can call an API without understanding whether the request succeeded, partially succeeded, or created a duplicate side effect.

Adding tools and databases does not automatically create AGI. It does show where the missing engineering problems are.

The model is not the memory

This is where vector databases enter the conversation.

A basic retrieval-augmented system is easy to describe:

query
  -> embed query
  -> find nearby vectors
  -> put matching chunks in the prompt
  -> generate an answer

Vector search is useful because it makes semantic similarity queryable. Embeddings represent text as points in a high-dimensional space, and indexes such as HNSW make nearest-neighbor search fast enough to use in applications. Filtering, hybrid search, and reranking can improve the candidate set.

But a vector database answers a narrower question than people often ask of it.

It can answer:

Which stored items look related to this query?

It cannot, by similarity alone, answer:

Which of these items still describes the world as it is now?

Imagine an event log with these entries:

E12: Alice owns authentication.
E31: Authentication ownership moved to Bob.
E57: Authentication work was canceled.

All three events are relevant to the question “Who owns authentication?” A vector database has not failed if it returns all three. It has found semantically related evidence.

The failure happens when the rest of the system treats relevance as truth.

A stateful system needs another layer:

query
  -> retrieve candidate events
  -> resolve time and status
  -> detect replacements and cancellations
  -> verify provenance
  -> construct current context
  -> answer

The vector database is still useful. It is a candidate generator. It is not the source of truth, the state resolver, or the memory policy.

This distinction matters for AGI because general intelligence is not just recognizing related patterns. It is knowing which patterns still apply.

Context is not continuity

A large context window gives a model more room to read. It does not automatically give the model a persistent understanding of what happened.

Context is closer to working memory. It is available for the current computation, but it has to be selected and organized again later. A million tokens can contain a project history, but it can also contain old owners, canceled requirements, duplicate decisions, and contradictory plans.

Memory needs more structure than a pile of text.

const memoryItem = {
  subject: "authentication",
  value: "owned by Bob and canceled",
  status: "current",
  validFrom: "2026-08-14",
  supersedes: ["E12", "E31"],
  sources: ["E57"],
};

The exact schema is not the important part. The important part is that the system can distinguish current facts from historical ones, preserve the source of each fact, and exclude information that should not influence a current-state decision.

I tested a small version of this idea in a benchmark to assess changes in the software project context. It compared a full project history, traditional TF-IDF retrieval, and a selective-memory table that explicitly marked information as current, updated, outdated, canceled, usable, or ignorable.

The benchmark used 90 simulated events and 30 questions. After manually auditing the saved responses, the results were:

The result I cared about most was not that one table won a small benchmark. It was that retrieval coverage and answer correctness were different measurements. RAG retrieved at least one supporting event for 28 of the 30 questions, but it did not answer all of those questions correctly.

Finding related information is not the same as resolving the state described by that information.

The result also had an important cost. Selective memory was the most accurate condition, but the slowest. The benchmark was small and simulated, so it does not prove that this architecture is always better. It does show why an AGI system needs to optimize accuracy, latency, token cost, freshness, and provenance together rather than treating any single metric as intelligence.

Tools turn language into action

An AGI that can only describe an action remains separate from the environment where the action matters.

Tools close that gap, but they introduce a new class of problems. A tool can time out. An API can return a partial result. A writer can succeed even when the response is lost. Two retries can create two records. A model can have permission to call a tool without sufficient evidence that it should do so.

That means an agent needs more than tool names in a prompt. It needs discovery, permissions, validation, idempotency, error handling, and verification.

The basic loop starts to look like this:

while (!goalComplete) {
  const observation = await observeEnvironment();
  const candidates = await retrieveRelevantContext(observation);
  const state = resolveCurrentState(candidates);
  const action = await chooseAction(state);
  const result = await executeValidatedTool(action);
  await verifyOutcome(result);
  await updatePersistentState(observation, action, result);
}

The last two lines are what many demos leave out. An agent that acts without checking the result is not autonomous. It is just producing side effects with confidence.

The same applies to tool discovery. Sending every tool schema into every model call is the tool equivalent of sending the entire project history into every prompt. A better system can search the catalog, inspect the few relevant schemas, validate access, execute the call, and return a compact result.

Vector search can help find the right tool. It has not yet been decided whether to use the tool.

Remembering is not learning

These concepts are often collapsed into one word, but they are different:

context  = what the system can use right now
Memory is what the system preserves across interactions
Learning is how future behavior changes from feedback
training = how model parameters are changed

Writing a new event to a database is memory-intensive. It is not necessarily learning. A model can retrieve a previous failure and make the same mistake again.

For an AGI-like system, learning probably needs multiple timescales. A temporary observation can affect the next decision. A verified project fact can update the persistent state. A repeated pattern can become a procedure. A large collection of high-quality examples can eventually become a training signal.

This is one reason I am skeptical of the idea that AGI can be achieved simply by increasing the context window. More context improves access to information. Learning requires a feedback loop that changes future decisions.

The system has to detect what happened, determine whether the outcome was good, update the correct state, and avoid turning a single noisy result into a permanent false belief.

Generality means transfer and recovery

An agent that answers questions across ten domains is not necessarily general. It may have memorized ten patterns.

The harder test is what happens when the task, environment, or available tools change simultaneously.

new task
new environment
missing tool
contradictory state
failed action
delayed feedback

Can the system form a useful plan without a perfect template? Can it discover the interface it needs? Can it recognize that an old assumption is no longer valid? Can it recover from a failed action instead of repeating it? Can it explain what it knows, what it inferred, and what it still needs to verify?

Those are not just model questions. They are system questions.

I would evaluate an AGI-like system across at least four dimensions:

• transfer to unfamiliar tasks
• performance over long time horizons
• recovery from errors and changing state
• safety and reliability at action boundaries

The score should include more than accuracy. It should include stale-state errors, unsafe actions, latency, cost, tool failures, provenance, and how often the system knows to stop and ask for help.

What AGI might actually look like

I do not think AGI will feel like a single chatbot suddenly becoming conscious. I think it will feel like a system that can enter a new environment and maintain a coherent loop inside it.

goal
  -> build working state
  -> retrieve relevant evidence
  -> choose an action
  -> execute it safely
  -> inspect the result
  -> revise the plan
  -> preserve what changed
  -> continue later

The model matters. It may be the most flexible reasoning component in the loop. But a model without state is forgetful, a model without tools is isolated, a model without feedback is ungrounded, and a model without evaluation cannot reliably tell whether it succeeded.

Vector databases may be part of the solution. They are useful for finding candidates in a large information space. They are not remembered by themselves.

Large context windows may be part of the solution. They make more evidence available. They are not continuous by themselves.

Tools may be part of the solution. They let the system act. They are not judged by themselves.

Training may be part of the solution. It gives a model broad capabilities. It is not a substitute for current state and real-world feedback.

AGI, if the term proves useful, is probably what happens when these pieces come together to form a reliable system that can adapt over time.

That is the part I find more interesting than the finish line. Not whether a model gets a new label, but whether it can take a goal, understand what is true now, do something in the world, learn from what happened, and still know where it left off tomorrow.