How gjalla works

Read this first. It is the whole model in one page: what gjalla holds, how you reach it, what you put back, and why the answer keeps improving. Every other guide is detail on one part of it.

The problem we’re solving

Agents are probabilistic, creative, and easy to talk to. That’s what makes them so powerful. It’s also why they need much better infrastructure around them before you can trust them to reliably give you what you want.

It turns out that infrastructure has become its own challenge to manage:

• Making sure each agent has the right memories
• Making sure it knows which rules to adhere to
• Making sure your skills aren’t overlapping, or even contradictory

All this stuff the agents rely on either makes them really effective or really annoying. We want you to have really effective agents.

What gjalla holds

Four kinds of thing, shared by every agent working in the project.

It works with whatever agents your team has chosen, so one shared setup covers Claude Code, Codex, Cursor, Gemini, and the rest.

How it reaches you

Three surfaces, same content behind all of them.

• The CLI: gjalla rules show, gjalla memory show, gjalla state show. Cache-first, so it works offline after a sync. Available to every agent that can run a command.
• MCP: the same context as tools, hosted by URL or run locally, for agents and editors that speak it.
• Native files: gjalla sync installs rules, skills and guidance into the files, hooks and skill directories each agent already reads, so much of it arrives without anyone asking for it.

Process rules are the exception to “content”: they compile into your agent’s own hooks and stop a disallowed command before it runs, rather than flagging it in review afterwards. You cannot talk your way past one, which is the point. It costs a blocked command instead of a wasted implementation.

What you put back

This is the half that is easy to skip and shouldn’t be.

• Memories: gjalla memory save when you learn something durable and non-obvious.
• Attestations: at each commit, what changed, which rules applied, what the impact was.
• The ledger: gjalla ledger mark as each step actually happens, so the record is timestamps rather than a summary written afterwards.
• Telemetry: recorded alongside the above, which agent did what, at what token cost.

None of it is paperwork. It is the input that keeps everything in the previous two sections true.

What comes back

Because agents report, gjalla can hand back more than it was given:

• Curated context rather than an accumulating pile. Duplicates consolidated, contradictions caught, stale entries flagged, gaps worth filling surfaced, across memories, rules and skills alike.
• Findings on what changed and what needs attention, from reviews and from drift between what was specified and what shipped.
• A ranked shortlist of what matters right now, so triage starts from something better than the full list.

The contradictory decision you would otherwise have discovered by tripping over it gets caught before you arrive.

Layering: platform, system, project

Everything shared (rules, skills, context, memories) resolves through the same three layers.

Platform content is gjalla-managed defaults, the same for everyone. System content is shared across all projects in a system. Project content is yours alone.

When layers conflict the rule is simple: project beats system beats platform. Name a skill or instruction the same as a platform default and yours wins, so you can safely tweak one without losing the original.

Agent credentials and MCP tools take the same scope / scopeId pair, so pick by who the thing is actually for. A team-wide standard belongs at team scope rather than copied into every codebase.

It gets better over time

The point of reporting is not the individual record. It is that the picture accumulates.

Telemetry is the clearest case. Humans and agents can read the same record of which agents made which changes, at what token cost, and with what outcome, and use it to work on two things together: token efficiency, and the quality and security of what gets produced. An agent can see where it spent tokens badly. A human can see where output quality or a security-relevant pattern needs a rule rather than a reminder.

None of this is a state you reach and finish. Maintaining the context, improving it, curating it, learning from what actually happened, is ongoing work. It is also the work that makes every future session start further ahead than the last one did.

The point

No surprises. Your agents have the information you think they have, they know how to do things the way your team does them, and the operational glue around them is managed instead of scattered across tools. Change a rule or a memory once and every agent picks it up on its next sync.

Where to go next

• Get started: connect a codebase and install the harness.
• gjalla CLI: the command surface, and the orientation routine if you are an agent.
• MCP server: the same context as tools, plus the full tool reference.
• Attestations and telemetry: how to record what you did, and what the record buys you.

Co-build with us

If this is a problem space you’ve been facing or iterating on, we’d love to hear from you (hello@gjalla.io). We’re evolving these paradigms and co-building with our early adopters.