perfloop
Closed-Loop Performance Engineering
Performance.
End to end.
Verified.
Find waste, map it to code, produce the change, and verify the result in production.
Commonplane, Inc.
Tomás Senart · Overview · April 2026
What Perfloop Does

Closed-loop performance engineering from bottleneck to proof.

Perfloop explains the bottleneck, takes the next safe step, and builds proof in the customer's environment.
That step may be a PR, an instrumentation change, a benchmark, or another policy-safe action.
First install
One repo or service area, one telemetry surface

Guided onboarding to start. GitHub plus one telemetry or profiling surface is the fastest honest first slice.

The Champion
Platform or performance engineer

Escapes the manual vendor hop. Gets a case they can review, run, and reuse instead of another investigation thread.

The Buyer
Head / VP Engineering

Buys faster performance engineering, less specialist drag, and lower runtime or cloud waste where the workload matters.

Proof bar
One real case carried end to end

Pick one important workload, explain it, take the next allowed step, and show either better performance or stronger proof in the customer's environment.

Trust is earned one bounded case at a time.
What One Pilot Produces

What the pilot delivers is a durable performance case.

The case holds the explanation, the next allowed step, the validation path, and the proof result or proof gap. Underneath, Perfloop learns how each customer's systems, deploys, proof surfaces, and action boundaries actually work.

What the loop does
  1. Map the relevant system slice
  2. Establish the right baseline
  3. Explain the bottleneck across runtime and code
  4. Identify the highest-confidence next step
  5. Open the PR or take the next allowed step
  6. Validate the result or close the proof gap
  7. Learn from the outcome
What the case contains
  • Selected performance case and system slice
  • Baseline and comparability context attached
  • Bottleneck and likely cause explained
  • PR, instrumentation step, benchmark, or other next allowed step
  • Validation method, measured result, or explicit proof gap
How It Works

Start from current state. End with proof.

An onboarding slice, current workload, regression, deploy, code change, or telemetry signal becomes an explained bottleneck, a bounded step inside policy, and stronger proof.

1. Trigger
Connect source control and map one system slice

Start with GitHub and one telemetry surface. Guided onboarding establishes the first honest slice of the system and where proof can happen.

2. Start from current state or a live signal
Current workload, regression, deploy, code change, or runtime signal

The loop can begin from onboarding, the current state of a workload, or a fresh signal the team already cares about. Perfloop picks the right baseline and follows the evidence into code.

3. Cross-runtime and code reasoning
Perfloop explains the bottleneck

Telemetry, deploy context, profiler evidence, and source are joined into one explanation of the bottleneck, why it matters, and the next safe thing to do about it.

4. Safe action + verified result
Perfloop opens the PR or takes the next allowed step

If customer policy allows it, Perfloop opens the PR, runs the instrumentation step, or takes the next allowed action. After merge, measurement, or recheck, it records what actually helped.

Why this works instantly
  • Guided onboarding with one repo and one telemetry surface
  • Starts from existing state first; adds instrumentation or profiling only when needed
  • Strongest where telemetry and code context are fragmented
  • Evidence trails, strong guardrails, scoped permissions, and human review keep trust high
  • Measured progress replaces hand-wavy ROI
Baseline → Explain → Change → Prove
Why Not Just A Feature

Observability vendors can add AI features. Perfloop is built for performance engineering.

Many teams still run more than one telemetry system. Observability vendors optimize inside their own stack; Perfloop is specialized for performance engineering across the fragmented reality teams already have.

Why this is hard as a feature
They are strongest inside one stack
Investigation and automation can get strong when the data, context, and actions all live in that platform.
They are incentivized to keep the workflow there
Cross-tool evidence, code, deploy history, and proof still spill back to humans in mixed environments.
Performance engineering is one use case among many
It is hard to be best-in-class at this loop when the core product is observability at large.
Continuous proof is expensive without memory
Without a persistent model of the customer environment, each new case burns fresh queries, tokens, and human attention.
Why Perfloop can win
Works across common telemetry vendors and code
It is strongest in the multi-vendor reality teams already have, not only in single-stack monocultures.
Built for one job: performance engineering
The whole system is optimized around baseline, explanation, action, and proof for this specific use case.
Act within policy
If the customer allows it, Perfloop opens the PR or takes the next allowed step inside the current granted scope.
Accumulates operating-model memory
It learns the account's system structure, proof paths, and action boundaries, which makes continuous operation cheaper to run over time.
Measured on live systems. Strongest where telemetry, code, and deploy context are fragmented.
Why It Compounds

The moat is customer operating-model memory.

Perfloop does not have to rediscover the same system on every case. It remembers how the account is wired, which proof paths are trustworthy, what actions are allowed, and what has already worked.

What The Customer Buys First
One real case. One bounded step. One validation path.
This is the narrow trust loop the market can buy first: one important workload, one action inside policy, and one measured result or explicit proof gap.
Simple outside. High proof bar.
What Gets Better Over Time
Ranked opportunities, proof history, and allowed actions.
Over time Perfloop learns repos, services, telemetry surfaces, deploy semantics, trusted proof methods, approved action boundaries, and measured outcomes. That makes the next case faster to understand, safer to act on, and easier to rank by expected value.
The visible product becomes a buyer-legible portfolio of ranked opportunities. The compounding asset is the learned account model.
Why It Gets Cheaper To Run
Continuous operation gets cheaper because the system reuses what it already learned instead of burning fresh queries, tokens, and human time to rediscover the account from scratch.
Commercial Motion

Start with narrow paid pilots. Expand into recurring revenue.

The first accounts share the same traits: one painful workload, a fast path to proof, and a buyer who cares enough to act. If the proof lands, the recurring product becomes a buyer-legible portfolio of ranked performance opportunities.

Pilot Offer
$25K fixed scope

30 days, one team, one repo or service area, one telemetry or profiling source, one meaningful workload. Can run in the customer's environment when trust boundaries require it.

100% of pilot spend credits toward the year-one platform fee if the account converts.
Best-Fit Accounts
Painful, measurable, easy to scope

The first wins should come from workloads with a clear owner, a clear before-and-after story, and a short path from install to honest proof.

The early goal is not breadth. It is one undeniable external win.
Recurring Product
Ranked opportunity portfolio

Buyer gets the highest-value performance opportunities ranked by quantified value, confidence, and next move. This is bought like an always-on performance engineering function.

Illustrative Buyer View
Checkout API
p95 latency bottleneck
-180ms expected value
PR ready
Nightly re-reads
serialization overhead
-22% runtime cost
benchmark first
Auth proxy
tail latency hotspot
-340ms p99 path
instrumentation step
Priced as an annual platform fee plus usage credits. The recurring product is the portfolio plus the execution loop that works the best opportunities over time.
Commercial Logic
The first commercial unit is a bounded pilot, not per-seat developer tooling. Choose early accounts for proof quality and speed, not for logo vanity or theoretical market size.
Founder Fit

I built the production AI substrate inside Axiom. Perfloop is the focused product built from it.

Founder
Tomás Senart
Principal Engineer at Axiom. Creator of Vegeta. Built the production AI substrate inside Axiom: infrastructure that reads live production evidence, joins it to code and deploy context, and acts safely inside real production workflows.
Advisor
Seif Lotfy
Co-founder & CTO at Axiom.
Advisor
Neil Jagdish Patel
Co-founder & CEO at Axiom.
Vegeta
Performance intuition
Petabyte systems
Infrastructure depth
Live systems
Production proof
The Advantage
Performance intuition, systems depth, and live proof.
The underlying production AI substrate runs on live systems inside Axiom.
Performance
Created Vegeta and spent years on benchmark design, load generation, and performance failure modes.
Infrastructure
Built core Axiom event infrastructure for petabyte-scale workloads.
Live proof
The substrate runs across telemetry, deploy context, and code inside Axiom.
Setup
Clean spinout, clean IP, and warm design-partner paths reduce execution risk.
What This Phase Proves

Now the job is paid proof. External and measurable.

The next phase is turning internal proof into a measured external win with disciplined, bounded pilots outside Axiom.

Already true
  • The production AI substrate runs on live systems inside Axiom with real runtime, code, and deploy context
  • Service-principal trust architecture, evidence trails, guardrails, and human review are already live
  • The pilot shape is narrow: one real case, one bounded step, proof in the customer's environment
This next phase builds
  1. Turn 2-3 strong design-partner conversations into paid 30-day pilots
  2. Turn the first pilot into one redacted measured proof artifact and one repeatable external win
  3. Complete SOC 2 and the minimum self-serve deployment path
This next phase proves
  1. A head-of-engineering buyer will buy this as faster performance engineering and headcount leverage
  2. A pilot can cut time from slow path to an evidence-backed step and validation
  3. One external account becomes referenceable on measured latency, throughput, or runtime-cost improvement
  4. The first wedge behaves like repeatable software across accounts, not bespoke consulting work
Paid proof first. One measured external win changes the company.
← → navigate