What is an agentic workflow?

What is an agentic workflow?

An agentic workflow is software where a large language model doesn't just answer a prompt and stop. The model plans, calls tools — search, file reads, shell commands, code edits — observes the results, and loops until the goal is met. The loop is the difference between a chatbot and an agent: a chatbot tells you what might work; an agent tries it, reads the test output, and fixes what broke.

Coding agents like Claude Code, Cursor, and Open Context Engine's Trace workspace are agentic workflows. A typical loop for "fix the failing test": retrieve the failing test and the code under it, read the implementation, form a hypothesis, edit the file, run the test, read the new failure, edit again. Every step feeds the next — which is why the quality of each step's inputs compounds.

Why code retrieval is the bottleneck

An agent can only act on what fits in its context window, and a real codebase is orders of magnitude larger than that window. So every agentic workflow over code is secretly a retrieval problem: what the agent's search puts in front of it determines the plan it forms. Weak retrieval produces the classic failure modes — hallucinated APIs, edits to the wrong file, "fixes" that break callers the agent never saw.

Naive approaches don't hold up. Pasting whole files burns the context budget on code that doesn't matter. Plain vector search misses exact identifiers ("find AbortWithStatusJSON" is a lexical query, not a semantic one). Plain keyword search misses paraphrases ("how does auth middleware work" never names the function). Hybrid retrieval — dense vectors fused with BM25 keyword scoring over an AST-aware index — is what makes the grounding precise enough to trust, and it's measurable: recall@k, MRR, and nDCG against committed gold sets, not vibes.

MCP: the standard that connects agents to your code

The Model Context Protocol (MCP) is the open standard that lets LLM applications call tools — search, file reads, symbol lookups — through one interface. An MCP server exposes the tools; agents like Claude Code and Cursor connect as clients. That turns "give the agent my whole codebase" from a prompt-hacking exercise into an integration:

npm install -g @dhaxor/open-context
claude mcp add oce -- oce mcp        # Claude Code, stdio
oce mcp --http --port 8940 --auth-token $TOKEN   # Cursor / HTTP clients

Once connected, the agent gets codebase-retrieval (hybrid search), repo-map (the codebase's structure in a few thousand tokens), find-symbol-definition / find-symbol-references (compiler-grade with a language server, AST-grade without), and read-file — all served from a local index that updates as files change.

Grounding beats guessing

The difference between an agent that helps and one that hallucinates is rarely the model — it's whether the model saw the real code. Three properties make grounding trustworthy:

• Measured retrieval. Ranking quality should be scored against gold sets in CI — recall, MRR, nDCG — the way tests are. OCE publishes its numbers and ships the harness to score your own repo.
• Visible context. You should be able to see what the agent knew — which chunks were retrieved, what was pinned or evicted — not just what it did. That's OCE's evidence rail.
• Local by default. Indexing your codebase with a cloud service means sending your source somewhere. Local-first embedding (in-process MiniLM) and local SQLite keep the loop on your machine; remote providers are an upgrade, not a requirement.

An agentic workflow you can run today

OCE is both a retrieval engine for your existing agent and a coding agent of its own:

# ground Claude Code / Cursor in your codebase (MCP)
npm install -g @dhaxor/open-context
oce index && claude mcp add oce -- oce mcp

# or use the built-in agent with the evidence rail
oce trace

The core is MIT and runs fully offline. The docs walk through Claude Code, Cursor, search modes, and team index sync; the benchmarks show what the retrieval actually scores.

Frequently asked questions