ambient-code.ai

GPS: A Global Positioning System for AI Agents

Q: Every large engineering org has tribal knowledge. The people who know where to look, who to ask, which spreadsheet has the real numbers. What happens when agents inherit that same dependency on tribal knowledge?

Jeremy: They ask for help. Same as humans do, but faster and with less ability to recover independently.

The information that drives our decisions lives in five or more disconnected systems: ticketing, corporate directories, release schedules, and spreadsheets. Each one has its own login, its own query language, its own data format.

Right now, getting a straight answer to a question like “who owns the inference component and what’s their current bug load?” requires a person who knows that the team spreadsheet uses a unique naming convention, and that the component mapping lives somewhere else entirely. That person cross-references three systems in their head.

That tribal knowledge tax is real. Onboarding a new senior hire takes 12-16 weeks when tribal knowledge is high, versus 4-6 weeks on well-documented teams. Multiply that across enterprise development teams, and the cost is staggering.

Agents are only as good as the data they can reach. Tribal knowledge is, by definition, unreachable to them.

Q: So your answer is to give agents an API-based discovery endpoint. Not a chatbot or search bar. An MCP server that agents query programmatically. Why that shape?

Jeremy: Because agents don’t need documents. They need structured answers they can act on. And I didn’t say no to chatbots or human interfaces to the same MCP. Slackbots were built for this!

Think about what happens when a human asks “who is on the Inference team?” A human can open a wiki page, scan a table, mentally filter out the people who transferred last month, and build a working mental model. An agent can’t do that. It needs a response that says: here are the current team members, here are their roles, here are the Jira components they own, here is their manager. Structured, current, machine-parsable.

The system I built is called GPS, as in Global Positioning System. It tells agents where things are in the organization. People, teams, features, releases, policies, components. Underneath, an Engineering Data Layer reconciles it (because systems do things like call me “Jeremy Eder” or by my GitHub, and the team spreadsheet uses a third variation), and serves it through purpose-built MCP tools. Not raw data dumps. Specific tools: lookup_person, list_team_members, search_issues,get_feature_status, release_risk_summary, list_documents.

The key design choice is that the agent never sees credentials to any system of record. It is air-gapped. Agents query GPS. GPS queries reconciled data. It’s read-only by design. This matters for security and for trust. You want to know exactly what the agent can see and you want to guarantee it can’t change anything.

Q: Let’s make this concrete. You have GPS running right now. I’m going to throw some real questions at it. What can it actually answer?

Jeremy: Go for it. These are all questions that used to require a specific person who knew where to look.

“When is the next release, and are we at risk?”

This is the classic program management question. Before GPS, you’d check Product release pages for the schedule, then open a spreadsheet to see which features are tracking, then cross-reference Jira to see if the work is actually getting done.

GPS handles it in one call:

→ Tool: release_risk_summary()
→ Returns:
  {
    "release": "v2.19",
    "milestones": [
      {"event": "Code Freeze", "date": "2026-04-01"},
      {"event": "GA", "date": "2026-04-22"}
    ],
    "at_risk_features": [
      {
        "feature": "JIRA-14032",
        "title": "Structured Output Support",
        "progress_pct": 62.0,
        "days_to_milestone": 13,
        "rice_score": 28.5,
        "owner": "Jane Smith",
        "team": "Model Serving"
      }
    ],
    "summary": "1 of 12 features below 80% with milestone in 30 days"
  }

The agent now knows there’s a risk. It can flag it in a Slack channel, add it to a report, or factor it into a planning conversation. No human had to open three systems and do mental arithmetic.

“Who is on the Inference team, and what components do they own?”

This one is deceptively hard. The answer lives across three systems that don’t agree on names.

→ Tool: list_team_members("Inference")
→ Returns:
  {
    "team": "Inference",
    "pm": "Alexa Chen",
    "eng_lead": "Mario Rodriguez",
    "members": [
      {
        "name": "David Park",
        "role": "Engineer",
        "components": ["vllm", "triton"],
        "fte_fraction": 1.0,
        "email": "user@domain.com"
      },
      {
        "name": "Steve Kim",
        "role": "Engineer",
        "components": ["vllm", "model-mesh"],
        "fte_fraction": 0.5,
        "email": "skim@domain.com"
      }
    ],
    "total_members": 8
  }

GPS reconciled “D. Park” from corporate directory, “dpark” from Jira, and “David Park” from the team spreadsheet into one person. The crosswalk handles these name mismatches automatically. An agent asking this question gets a clean, unified answer without knowing or caring that the upstream data was a mess.

“What does our AI policy say about model evaluation?”

Governance documents were PDFs buried in Google Drive.GPS extracted them into searchable, structured sections.

→ Tool: list_documents(doc_type="policy")
→ Returns: [{doc_id: 1, title: "AI Engineering Policy", ...}]
→ Tool: get_document_section(doc_id=1, heading="model evaluation")
→ Returns:
  {
    "heading": "Model Evaluation Requirements",
    "level": 2,
    "content": "All models deployed in production must undergo evaluation
     against the standard benchmark suite. Results must be documented and
     reviewed by the model owner and at least one peer before deployment.
     Evaluation criteria include: accuracy on held-out test sets, latency
     at p95, resource utilization, and bias assessment..."
  }

An agent building a deployment pipeline can now programmatically check whether it’s in- or out-of-policy. No human needed to remember which Google Doc to look in.

“Show me all critical bugs in the Dashboard component that are still open.”

→ Tool: search_issues(
    priority="Critical",
    status="Open",
    component="Dashboard"
  )
→ Returns:
  {
    "total": 3,
    "issues": [
      {
        "key": "JIRA-18442",
        "summary": "Dashboard crashes on cluster with >50 namespaces",
        "assignee": "Tom Wilson",
        "created": "2026-03-01",
        "updated": "2026-03-15"
      },
      ...
    ]
  }

This query spans people, components, and Jira data. Before GPS, you’d need to know the exact component name (which doesn’t always match what teams call it), build the right JQL, and run it. GPS handles the fuzzy matching and cross-referencing.

“What’s the status of the Guardrails feature?”

→ Tool: get_feature_status(title="Guardrails")
→ Returns:
  {
    "issue_key": "JIRA-12501",
    "title": "Guardrails",
    "issue_status": "In Progress",
    "progress_pct": 98.5,
    "rice_score": 34.2,
    "teams": ["Safety", "Model Serving"],
    "releases": ["v2.19", "v1.5"],
    "dev_approval": "Approved",
    "qe_approval": "Pending",
    "docs_approval": "Not Started",
    "target_milestone": "2026-04-01"
  }

Feature status used to require checking all those datasources and then reconciling them manually. GPS pulls from the reconciled data layer, so the answer is provided in realtime, and consistent regardless of who asks or when.

Q: You’re calling this GPS, as in Global Positioning System. That’s a familiar name. And you’ve also been positioning it under the industry concept of Continuous Decision Intelligence. What’s the connection?

Jeremy: GPS is the project. Continuous Decision Intelligence is the category it belongs to.

I named it GPS because that’s what it does. It tells agents where things are. Where is this person in the org? Where is this feature in the release cycle? Where is this policy documented? Where is the risk? Agents navigating a complex organization without GPS are driving without a map. They can move, but they don’t know where they’re going.

The industry has a name for this pattern. In Gartner’s August 2025 Hype Cycle for Artificial Intelligence, Decision Intelligence was classified as a “transformational” technology, defined as “a practical discipline that advances decision making by explicitly understanding and engineering how decisions are made, and how outcomes are evaluated, managed and improved via feedback.”

It’s about to get real:

It also feels like developers are an underserved market for decision intelligence automation, and agents are the perfect excuse to put an API in front of it.

The “continuous” part matters. The Engineering Data Layer has to be versioned, and have authoritative information with audit logging. When an agent asks a question, it gets the current state. Continuous ingestion, continuous reconciliation, continuous availability. We’re looping again!

CDI has been applied to supply chains and logistics by other companies. What I built applies the same pattern to engineering organizations. The data sources are different (Jira instead of shipping manifests, org charts instead of warehouse inventories), but the principle is identical: unify fragmented data, keep it current, and serve it through an interface that enables both humans and agents to make informed decisions in real time.

The timing is right. Gartner predicts 40% of enterprise apps will feature task-specific AI agents by the end of 2026, up from less than 5% in 2025. Those agents will need organizational context to function. GPS and MCP are how I’m providing it.

I didn’t set out to build a “CDI system.” I set out to solve a specific problem: my agents couldn’t answer basic organizational questions. But when I looked at what the industry calls systems that do what GPS does, Continuous Decision Intelligence is the closest fit. It gives people a frame of reference for what this is and why it matters.

Q: GPS gives agents organizational awareness. But an agent writing code also needs to understand the codebase itself, the patterns, the abstractions, the “how we do things here.” You’ve been working on something for that. What is it?

Jeremy: Still banging around with it, but yeah it’s called Steering. And it’s the other half of the picture.

GPS tells agents where the org is. Steering tells agents how to write code correctly for a specific codebase in a context–optimized, LLM-friendly map. It analyzes a repository using tree-sitter to extract the full structure: every function, class, method, and interface. Then it generates structured guidance. When to use a helper versus writing inline. Which API to call. What patterns the codebase expects. Full function signatures with types, parameters, and docstrings. I am not an expert at this, but I do understand there is a deep field around code analysis. To gain confidence in this, we need to measure its effect under a variety of circumstances, languages, and topologies.

The output is served through an MCP server, same as GPS. So an agent gets both organizational context and codebase intelligence through one protocol. It can ask GPS “what team owns this component?” and ask Steering “what’s the right pattern for adding a new API endpoint in this repo?” in the same conversation.

I want to credit Tessl here. Guy Podjarny (who founded Snyk) started Tessl to tackle a similar problem: giving agents structured context about codebases through what they call spec-driven development. Their approach uses authored specs and documentation tiles to teach agents how to work with a codebase. It’s early but thoughtful work.

Steering is its own deep topic, and I’ll write about it in a follow-up post. For now, the key insight is that GPS and Steering together give agents two more reasons to stop AskUserQuestion: knowledge of the organization and knowledge of the code.

Sources

1. Gartner Hype Cycle Identifies Top AI Innovations in 2025 – Gartner, August 2025
2. Gartner Predicts 40% of Enterprise Apps Will Feature Task-Specific AI Agents by 2026 – Gartner, August 2025
3. Donating the Model Context Protocol and Establishing the Agentic AI Foundation – Anthropic, December 2025
4. Tessl: Agent Enablement Platform – Tessl, 2025