Garth / Products / GKS
GKS GKS Context Layer · The Brain

One governed brain
behind every agent.

GKS connects your engineering ecosystem behind one governed boundary, turns your code, architecture rules, guardrails, and tickets into a tenant-isolated knowledge graph, and serves each Garth product, and your own coding agents over MCP, exactly the context the job needs, with every write-back running through your keys.

Book a demo See how it works
8+7Node & relationship types in your code graph
Your keysEvery read and write, on a boundary you govern
~35% fewer tokensContext served once, not rebuilt every agent session
YOUR ENVIRONMENT Git repos CI / CD Issues & PM Docs & Wiki Cloud infra Comms GKS THE BRAIN THE GOVERNED SPINE authorize isolate graph ground scope scoped context → every product GReview G360 GScan GRelease G-IDE GAssist your keys · your permissions every write-back passes through your keys

A graph, not fuzzy search

Your code becomes a deterministic property graph of files, classes, functions, calls, and imports, rebuilt on every commit. Not a pile of text chunks.

Deterministic by design

Governed by design

Every node is cryptographically keyed to your tenant. Only repos you authorize are ingested, and write-back runs on short-lived keys you control.

Your data stays yours

Grounded, not guessed

Deterministic IDs and an explicit absence protocol mean an agent knows when context was found, checked-and-empty, or unavailable. No hallucinated code.

Hallucination-resistant

One brain, every agent

GReview, GScan, G360, GRelease, GAssist, and G-IDE call the same SDK. Claude Code, Codex, and Cursor call it over MCP. Connect a repo once; the whole suite, and your agents, get smarter.

SDK and MCP
The governed spine

Every request travels the same governed spine.

Data doesn't reach an agent by accident. It passes, in order, through five stages, deciding what may enter, what stays isolated, and what a job is allowed to see, before any product is ever handed context.

01

authorize

Only the repositories and branches you activate are ever ingested. Nothing you have not connected enters the graph.

02

isolate

Every node is keyed to your tenant with a cryptographic ID. One tenant cannot address another's graph, by construction, not just a filter.

03

graph

Your code is parsed into a deterministic graph of files, classes, functions, calls, and imports, rebuilt on every commit.

04

ground

Answers carry an explicit absence protocol, found, checked-and-empty, or unavailable, so nothing downstream is ever invented.

05

scope

Each product gets only the context that job needs, assembled from the graph, and nothing beyond it.

Only then is context served. And every write-back, from GKS or any product, runs through per-tenant, short-lived keys you provision and revoke.

What it builds

Not fuzzy RAG. A deterministic graph of your code.

GKS understands structure, not just similarity: the dependency graph, the call graph, and the exact relationships between the things in your codebase.

Nodes in your code graph

Repository Folder File Class Function Variable Module Import

Relationships between them

DEFINED_IN HAS_METHOD CALLS IMPORTS EXPORTS RE_EXPORTS PR_CHANGE

Every node carries a deterministic, reproducible ID derived from your tenant, repo, file, and symbol, so the same function is the same node across every commit. No fuzzy matching, no duplicate graphs.

Virtual Mergeunique

GKS patches an open PR's diff over the committed graph in memory, so agents reason about unmerged code against production state, without ever mutating your source of truth.

Blast radius & conflicts

It walks the CALLS graph to find every function a change touches, and flags two open PRs mutating the same code before they collide in production.

Explicit absence protocol

Every answer states whether context was found, checked-and-empty, or couldn't be checked, so downstream agents never invent what isn't there.

One brain, every product

Everything the suite knows, it knows through GKS.

Each product asks the same brain for a different slice of the same governed graph. Connect a repository once, and all of them get grounded.

GReviewWhole-codebase review context and inter-PR conflicts
G360Repository and delivery signals for the ROI board
GScanCode and dependency structure for security scans
GReleaseChange surface and readiness state per release
G-IDEIn-editor context, grounded in the real graph
GAssistAnswers about the codebase, backed by the graph
Your coding agents · Claude Code, Codex, Cursor, WindsurfThe same architecture rules, guardrails, and ticket intent, served over MCP before the PR exists

One graph, assembled once and shared. Improve the brain, and every product gets smarter at the same time.

MCP

The same context, served to the agents that write the code.

GKS exposes its governed graph over MCP. Claude Code, Codex, Cursor, and Windsurf pull your architecture rules, guardrails, and the ticket's intent before the PR exists, instead of rediscovering your codebase at the start of every session.

Your agent asks

"How does billing call the payment service, and what rules apply?"

Claude CodeCodexCursorWindsurf
→
GKS answers over MCP

The call graph for billing → payments, the architecture rule that database access goes through the repository layer, the no-raw-SQL guardrail, and the acceptance criteria from PAY-2187. Scoped to this job, nothing beyond it.

→
Your agent builds

To your architecture and your guardrails, before the PR is opened. GReview then checks the result against the same context, as the independent second pair of eyes.

Served once, not rebuilt

A coding agent re-reads your codebase every time a session starts, and pays for it in tokens. GKS holds that context once and serves it on request. Across deployments, about 35% fewer tokens.

~35% fewer tokens

The same answer every time

Deterministic node IDs and an explicit absence protocol mean two sessions, or two agents, get the same context for the same question. No drift between what was written and what was checked.

Deterministic

Governed like every other read

MCP requests travel the same spine as every product: authorize, isolate, graph, ground, scope. An agent sees only what its job is allowed to see, and writes back only through your keys.

Your keys, your boundary
Deployment & residency

Runs in our cloud, or entirely inside your boundary.

GKS runs
Garth Cloud
On-prem

Multi-tenant in Garth Cloud. Your graph is isolated by cryptographic tenant identity, code is reduced to structure and metadata, and write-back runs on your own short-lived keys.

Included with every Garth plan

You don't buy the brain. You build on it.

GKS is the context layer under every Garth product, and the one your coding agents can read over MCP. Connect a repo, and the whole platform, and your agents, start reasoning about your code on a boundary you govern.

Book a demo Explore the suite