What AI work at GIKSN looks like
AI is where the lab actively works. The bet: AI agents keep almost working and then falling apart when the task gets real, and there are two specific reasons at once. The model does not have memory that gives it the right context at the right time. Even with good memory, small models still hit ceilings retrieval alone cannot fix. This post is a plain description of what we are actively building.
GIKSN Research is an independent lab. The AI sector is where our own bench sits. This post is a working statement of what we are building right now, why we picked these problems and how the work becomes tools rather than only papers.
The bet
AI agents have been almost useful for two years and mostly not. The reason is specific. The model running your agent does not have memory that reliably gives it the right context at the moment it needs to reason. Retrieval that returns approximate matches from a text dump is not the same thing as memory. On top of that, even if you fix the memory, small language models still hit real ceilings on planning, multi-step reasoning and coherence over long retrieved contexts.
Two problems have to be solved in parallel before AI agents work well. The memory that the model reads from. The model doing the reading. Working one side without the other produces impressive demos that fall apart when the task is real.
Thread one. What we mean by memory
Not chat history. Not vector search over documents you dropped into a folder. Real memory. The kind that remembers what happened yesterday. That knows what led to a decision. That connects a file to the thread you were reading to the command you ran three minutes later.
The current standard answer is roughly "shove more into the context window and use a bigger vector store." That gets you a demo. It does not get you a system that still works six months in. Vector search is right about the wrong things too often. Longer context windows dilute attention. Retrieval that grabs the top-k similar chunks is not the same thing as retrieval that grabs the one piece of state the model actually needs.
So the memory work is not building a bigger vector store. It is rethinking what memory itself is. What shape it takes. What kinds of queries make sense against it. How the schema survives change over a year of active use when what you thought was one kind of entity turns out to be three. How compaction preserves the useful bits and drops the noise rather than throwing away last week to save disk. How forgetting works when it needs to feel intentional instead of arbitrary.
Thread two. What we mean by the model doing the reading
Assume for a moment the memory is excellent. A small language model still has ceilings. Multi-step reasoning gets brittle around move three or four. Planning under uncertainty falls back to heuristics baked in during pretraining. Retrieved context of any real size dilutes across attention until coherence slips. Quantisation trades calibration for footprint. Distillation preserves the average case and drops the tail. Safety after aggressive fine-tuning is qualitatively different from safety in the base.
None of that gets fixed with better retrieval. That is the second thread. It runs at the same time as the memory thread because the two are the same problem seen from opposite ends. Memory decides what the model gets to see. The model decides what to do with what it sees. A lab that only works one side ships something that looks smart until it has to actually think.