Most days the lab is working on two questions. Both are about why AI agents keep almost working and then falling apart the moment the task gets real. The first is memory. The second is what a small model can actually do with that memory once it has it.

What we mean by memory

Not chat history. Not vector search over documents you dropped into a folder. The kind of memory 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 standard answer right now is roughly “shove more into the context window and use a bigger vector store.” That gets you demos. 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 instead of using it. 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 the memory is. What shape it takes. What kinds of queries make sense against it. How it survives a schema change six months in when what you thought was one kind of entity turns out to be three. How compaction keeps the useful bits and drops the noise, rather than throwing away last week's activity because disk got tight. How forgetting works when it needs to feel intentional instead of arbitrary.

What we mean by the model doing the reading

Give a small language model perfect memory tomorrow. It still hits 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 starts to slip. 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 model.

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.

Why these two

Both problems have been “next quarter” at every major lab for the last two years. Neither has been convincingly answered. What we noticed while sitting with the actual details is that the published research thins out fast once you get past the surface.

There is a lot of high-level writing on “memory for agents.” There is much less on what to do when the schema stops matching reality six months in, or when the retrieval ranker is right for the wrong reasons, or when the model confidently pulls from the wrong session because two similar-looking states got embedded near each other.

Small model limits get the opposite treatment. Everyone benchmarks. Almost nobody writes down the specific failure modes that ruin real deployments. The bet is that the space between surface writing and actual working systems still has room. A small independent lab can meaningfully add to the record if it works carefully.

What Rinne is doing in the middle of this

Rinne is the first tool the lab has shipped. It is an orchestrator you talk to from your terminal. You tell it what you want done. It plans the work into a graph, hands pieces of that graph to whichever coding-agent CLI or model API on your machine is best suited to the piece, and verifies each result before moving on. Nothing is hosted anywhere. Nothing phones home. Your API keys stay in your OS keychain.

Rinne is not the memory research. It came out of the memory research. While building the substrate that would give a small model context, we needed a way to actually run agents on our own machines to see how they behaved. Existing options either wanted a subscription, wanted a hosted account, or wanted us to pick one model family. Rinne was the tool we built for ourselves. Then we decided it was worth releasing.

Its paper lives in the AI sector. The next tools out of the lab will follow the same rule. They ship when they are useful. They land with a companion paper. The paper describes why we made the choices we made, including the ones we are not sure about.

The archive

Every paper has an abstract, a body, a category, an author line and a discussion thread underneath. The format borrows from technical RFCs. The tone is closer to a working notebook than a journal submission.

A paper here can be small. It can be a survey that turns out to describe a crowded subfield. It can be a draft someone abandoned halfway when the experiment they meant to run got expensive. Rejected directions stay in the archive because half the value of writing anything down is that later you can point at it and say “we already thought about this, here is why we did not do it.”

How categories work

Category marks what kind of work a post is. Four kinds.

• Research. Papers and technical work from the lab and contributors.
• Writings. Essays, notes and commentary that sit outside a formal paper.
• Products. Shipped tools and releases the lab has put into the world.
• Programs. Cohorts, fellowships and community work.

Category can change if a post grows into something else. If a writing turns into a research paper or a release graduates into a product page, update the category and leave a note so the trail is readable.

How the four sectors fit

The archive is organised across four sectors: AI, Deeptech, Hardware and Distributed Systems.

AI is where the lab actively researches. Almost every paper written by the lab itself is going to sit here for the foreseeable future.

Hardware and Distributed Systems are the two adjacent surfaces our AI work leans on. Any AI system that has to run somewhere is a hardware question. The compute substrate decides whether things are actually feasible or just interesting. Any memory system that has to survive real use is a distributed systems question. How do you shard it. How do you replicate it. How do you keep it consistent when everything is being written at once. The lab writes in these two sectors when the AI work produces something worth writing down about the surrounding infrastructure.

Deeptech is a longer horizon. Bio, materials, energy, quantum and robotics shape what is possible at the AI substrate over years rather than months. The lab keeps a small amount of survey writing here to stay honest about where things are actually moving.

Contributor writing is welcome in all four sectors and expected to be the majority in Deeptech, Hardware and Distributed Systems for the foreseeable future. Contribution is gated for reasons explained further down.

• Artificial Intelligence (AI). Where the lab actively works. Building the memory layer that gives AI agents the right context at the moment they need it. Researching the ceiling of small language models where retrieval alone stops helping.
• Deeptech (DT). Bio, materials, energy, quantum, robotics. A longer-horizon track the lab tracks and surveys, with contributor writing at the centre.
• Hardware (HW). Silicon, accelerators, NPUs, embedded systems, sensors. The compute substrate where AI actually runs. Where our AI work meets honest hardware numbers.
• Distributed Systems (DS). Consensus, storage, coordination, protocols. Where our memory work meets indexing and retrieval. The plumbing under any memory system that has to survive real scale.
• Updates (UP). Announcements from the lab and the wider frontier. Cohort openings, collaborations, releases, program dates.

Editorial process

Authors keep editorial control of their own papers. Editors copy-edit for clarity and fix typos. If we want to change the substance, we ask.

Discussion threads are preserved verbatim. If a comment gets removed for moderation reasons, a placeholder stays in the thread with a one-line explanation of why. We do not quietly disappear things.

Every author writes under their real name or a stable pseudonym they have used elsewhere. Anonymous throwaway accounts do not add much to a discussion thread and we do not have the moderation bandwidth to argue about it.

Community, alongside

This is the section where AI labs writing manifestos usually go wrong. So we wanted to write it carefully. The community is not the point of GIKSN. It is also not window dressing.

What the community actually is: readers. People commenting under papers. A small number of vetted contributors who write papers of their own here because it is a good place for the work to sit. A public Telegram channel where anyone can join. A private one for accepted contributors where working groups coordinate.

What the community is not: it is not the product. The lab does its own research first and the community forms around that research. If the research stopped, so would the community. We think that is the honest way around. We say it out loud because pretending otherwise is a common failure mode.

Anyone can read every paper on the site without an account. Anyone can post a comment. Anyone can apply to contribute. The application asks for evidence that the applicant understands the kind of work being done, because sustained contribution requires it. That is the whole wall.

Getting in touch

For questions about a specific paper, use its discussion thread. That way anyone else with the same question can read the answer later.

For questions about the lab in general: research@giksn.com.

For anything urgent (takedown notices, security issues, legal correspondence) the same address works. Put “urgent” in the subject line and it gets triaged first.

We read everything. Response times vary.

The record matters more than the verdict. Rejected directions stay because we want to remember what we considered.