Skip to content
Noy Oliel
esc
  • Home
  • All systems
  • Writing
  • Resume (printable)
  • AI assistant for a security SaaS
  • MCP server and OAuth for outside AI clients
  • SARA: agentic software factory
  • AI development toolkit for the team
  • In-house graph engine
  • Copy email addressoliel.noy@gmail.com
  • Open LinkedIn
  • Book an intro call
  • Signal
  • Overview
  • Timeline
  • Architecture
  • Inside
  • Hard problems
  • Decisions
  • Outcomes
  • VoidDefault. Near-black with signal blue.
  • DaylightLight, for bright rooms and printing.
  • ContrastHigh contrast, 7:1 text. Best on TVs.
  • TerminalPhosphor green on black.
  • InfraredWarm graphite with infrared orange.
  • Room: team review on a large screen
  • Desk: one reviewer
  • Calm: stop ambient motion
  • Full motion

00Case study · Jun 2026 – present

SARA: agentic software factory

My own initiative: a gated pipeline of AI agents turns a feature request or bug report into a reviewed, tested pull request.

StaffNot shipped · live demo

My roleMy own initiative: creator, lead and sole owner, built with AI coding agents under my design and review.

  • 121 API routes
  • 44 migrations
  • 638 test files
  • 12 model-provider adapters

01Overview

What it is, and why

SARA is my own initiative, self-funded so far: a software factory that makes software-development work agentic and automated. It turns a plain-English feature request or bug report into a reviewed, tested pull request. I have presented it to the CEO, the CTO and team leads, and other teams asked to use it. It is not shipped; a live demo is available.

Coding agents are fast, but left alone they skip steps. SARA runs them through a disciplined development process and enforces it in code: a stage passes only when its typed result meets its requirements.

It is aimed at two uses: the company’s own engineering, and a paid product for customers.

At a glance

How it works, in short

  • Request to pull request: agents run a gated pipeline (investigate, requirements, design, code, review, test); a stage passes only when its typed output meets its requirements, and failures send work back.
  • Grounded in the code: it builds a product-feature catalog and a code graph from a company’s repositories, so agents work from what the code actually does.
  • Model routing: each stage runs on a model tier (bulk, balanced, quality) across several providers, including local and open-weight models, with usage metering and spend caps.
  • One hard problem: open-weight models stopped after a single tool call, so I rebuilt their execution loop.
  • Next.js
  • TypeScript
  • Python
  • Postgres RLS
  • pgvector
  • Memgraph

02Timeline

How it came together

Jun 2026 to present.

  1. Jun 2026

    Started: dev pipelines, code graph, workspaces and roles.

  2. Jul 2026

    Isolation across stores, four-tier memory, the Bedrock lane.

  3. Aug 2026

    The open-model tool loop, Fireworks, the local Gemma interaction lane, tier-first model routing.

  4. Sep 2026

    Human steering, the run-state layer, spend tracking.

  5. Oct 2026

    SARA as an MCP server: export and import of tasks.

03Architecture

How the parts fit

The pipeline executor is the hub. Every stage reads the code graph, runs on its model tier, and writes runs and usage per workspace.

sara · one run

  • Ask and answer

    • RequestA feature request or bug report, in plain English or from a ticket
    • A personPauses, steers, approves learnings
    • Pull requestReviewed and tested

  • Pipeline · Next.js server

    • Pipeline executorStage loop, typed gates, send-back
    • Run workspaceCloned repositories, per-repo setup

  • Grounding, models and data

    • Code graph and catalogMemgraph; features built from the code
    • Model routerBulk, balanced and quality tiers
    • MemoryRecall pointers, pgvector, learning library
    • PostgresRow-level security per workspace
  1. Request to Pipeline executorStarts a feature or bug run
  2. Pipeline executor to Run workspaceClones the repositories and runs the code
  3. Pipeline executor to Code graph and catalogInvestigate against what the code actually does
  4. Pipeline executor to Model routerEach stage runs on its tier, across providers
  5. Pipeline executor to MemoryRepeated tool output becomes recall pointers; approved learnings come back
  6. Pipeline executor to PostgresRuns, usage and spend, scoped to the workspace
  7. A person to Pipeline executorPause and steer a run
  8. Pipeline executor to Pull requestOnly a passing, typed result moves on; review failures send work back
Point at a box or a flow to trace it. The numbers match the list.

04Inside the system

The parts that matter

  • 01

    A process agents cannot skip

    • Stages from investigate, requirements and design through code, review and test, each with a typed submit schema.
    • Mandatory requirements review, plan-only gating, and unfinished tasks that block progress.
    • Failures send work back to an earlier stage; a person can pause and steer.

  • 02

    Grounded in the code

    • A polyglot code graph: Python indexers resolve syntax trees and route tables, then load the graph into Memgraph.
    • A product-feature catalog built from the code by grouping and reconcile agents, anchored to the graph.

  • 03

    Models across vendors

    • Each stage asks for a tier (bulk, balanced, quality); the router resolves it to a provider and model.
    • 12 model-provider adapters: Claude, Bedrock, Fireworks, OpenAI-compatible, Codex and open models, plus a local Gemma model for always-on interaction.
    • A pre-run credential gate, a guard that fails loudly on mismatched vendors, and a usage ledger with prices and spend caps.

  • 04

    Memory a person curates

    • Four tiers: a context sweeper that replaces repeated tool output with recall pointers, semantic recall on pgvector, knowledge shared within a run, and a learning library.
    • A topic two or more stages agree on becomes a provisional learning; a person approves it before later runs see it.

  • 05

    Many workspaces, shared stores

    • Postgres row-level security through a transaction-local workspace setting.
    • Composite (id, workspace) keys in the graph and a query guard that fails closed.
    • Personal and organization workspaces with role-based access, and a leak-gate test that tries cross-workspace reads.

SARA pipeline

  1. S1InvestigateReads the code graph and feature catalog
  2. S2RequirementsMandatory review of the ask
  3. S3DesignPlan against real modules
  4. S4CodeModel tier per stage
  5. S5ReviewAgents and a person can steer
  6. S6TestTyped pass or send back

Send back on failure: Review returns work to Code

Each stage submits a typed result; a gate checks it before the next stage starts. Review failures send work back to Code.

05Deep dive

Hard problems

What stood in the way, what I did, and what came of it. Where nothing was measured, it says so.

Hard problem 01

Open-weight models that stopped after one tool call

Problem
Open-weight models served over an Anthropic-style messages transport narrated a plan, made one tool call and stopped. That made them useless as coding agents.
What I did
  • Tested the first hypothesis, prompt caching; disabling it alone did not fix the stall, so I rejected it.
  • Rebuilt the lane as a Vercel AI SDK loop over an OpenAI-compatible endpoint through a self-hosted LiteLLM proxy, with explicit stop conditions.
  • A bridge from the coding tools to AI SDK tools, with reply caps, abort propagation and a git-gated submit.
Result
Open models run full tool loops, two earlier drivers were retired, and the Claude lane is unchanged. Tool-call success rates were not benchmarked.

Hard problem 02

Isolation that fails closed

Problem
Every workspace shares the same Postgres and Memgraph instances. One missing filter would leak one organization’s code graph or runs to another.
What I did
  • Postgres: a transaction-local workspace setting and forced row-level security policies.
  • Memgraph: composite keys on every merge, traversal scoped by edge, and a guard that rejects queries without a workspace.
  • A leak-gate regression test that tries cross-workspace reads.
Result
Isolation is enforced by both stores and by a query seam, not by each caller remembering a filter.

Hard problem 03

Knowing a run is alive

Problem
Run state lived in one process. On a shared pool of dev instances, that is not enough to know whether another instance’s run is still alive.
What I did
  • A lease with a heartbeat on each run record in Postgres.
  • One set of run statuses, and a reconcile step at boot.
  • A run-driver seam, so the same runs can move to a workflow service later.
Result
One instance cannot declare another’s live run dead, or start a second executor for it.

06Decisions

Trade-offs I made

What I chose, what I passed on, and why.

  • Decision · Process

    Typed stage results, checked by gates

    OverInstructions in the prompt alone

    An agent can skip a step it was asked to take; it cannot pass a gate whose schema it has not filled.

  • Decision · Model choice

    Tiers per stage, resolved by a router

    OverA model hardcoded per stage

    Providers and models change. A stage asks for a tier, and guards fail loudly on a mismatch.

  • Decision · Open models

    A new tool loop over an OpenAI-compatible endpoint

    OverTuning the existing transport

    Disabling prompt caching was tested and did not fix the stall; a loop with explicit stop conditions did.

07Outcomes

What came of it

Measured or owner-stated

Results

  • Presented to the CEO, the CTO, team leads and my own team; other teams asked to use it.
  • 121 API routes, 27 pages and 44 database migrations.
  • 638 test files.
  • 12 model-provider adapters.
  • 3,849 commits since Jun 2026, as the sole committer.

Said plainly

Limits

  • Not shipped and not in production; a live demo is available.
  • No token, cost or latency figures are quoted, and tool-call success rates were not benchmarked.