Why we needed a place for the work
We were building software with coding agents. The instructions around each session kept growing: what to read, which decisions mattered, and where the work had stopped. Giljo HQ grew from the need to keep that background and the work connected.
We were developing software with coding agents. Giljo HQ grew out of the work around that development, rather than starting as a separate product idea.
The instructions around each session kept growing. Startup notes. Development notes. Rules about what to read first. Decisions that should not be reopened without a reason.
Those instructions were useful. But each new session meant pointing an agent back to them and filling in the background again.
The startup ritual kept growing
The product direction, earlier decisions and work in progress did not all live in one place. Files and conversations held different parts of the background. Bringing a fresh session up to speed became part of the job.
An agent needed to know what we were building, which constraints mattered, and where the previous session had stopped. Another instruction could tell it where to look, but that also meant more instructions to keep current.
Context budgets were tighter then. Long conversations could become harder to rely on, and starting fresh meant establishing the background again.
The coding tools used in that early work did not initially offer compaction: condensing earlier conversation to make room for a session to continue. When it arrived, the early results did not make the problem disappear. The tools and their context handling have improved since.
A place for the background
The first idea behind Giljo HQ was direct: define the product's intent, requirements and useful context in one place, and give an agent a way to ask for it when needed.
We also wanted agents to help keep that information current as the product changed. That did not mean handing product direction to an agent. We still needed to review proposed changes and decide which belonged.
It was a different place to keep the background, not a reason to stop checking it.
Then the work needed a place
Product context was only part of the problem. There was also the work itself: what needed doing, what was underway and what should wait.
Projects gave those changes a place under a product, with enough detail to understand and find them again. Recording projects and updating their state came first. The next question was how coding agents could help keep that record in step with the work, within boundaries we set.
That is how the scope grew. Product context described what we were building. Projects described the changes we wanted. Agent instructions described how to handle the work.
What belongs in this notebook
Models and harnesses have improved alongside that development. Giljo HQ has grown with their capabilities, rather than remaining fixed around the limitations of earlier tools.
The need is still familiar: a place for the product, the work and the decisions around it, without depending on one long conversation to hold everything together.
In this notebook, we share what we learn while building with agentic tools: what we try, what we check and what changes as the work develops. Some entries are practical guides. Others examine the decisions behind the tools we build.