# Polylane - Full Content

> The automation platform for modern infrastructure. Agents that read your code, watch your infra, and fix production before you wake up.

Polylane is built by Coreplane Labs in San Francisco, founded by Boris Tane (built Baselime, acquired by Cloudflare; led observability at Cloudflare). Pre-launch; early access rolls out from June 2026 via the waitlist at https://polylane.com. See https://polylane.com/llms.txt for the index version of this document, including the API endpoints agents can call.

## The loop

Polylane runs a closed loop over production software: **Detection** (agents watch your infra and detect anomalies before they become problems, reading actual signal series instead of thresholds), **Investigation** (agents work the incident with your real tools and show the receipts, in shareable transcripts), and **Remediation** (the fix arrives as a pull request with a regression test and the evidence trail; your review and CI still gate the merge).

The homepage walks one worked incident through all three steps: a critical P99 latency regression on a Cloudflare Worker named checkout-edge. Deploy 9f3c2a1 shrank the Hyperdrive connection pool hd-prod from 50 connections to 5; under checkout load, requests queued and P99 rose 18x (Wall Time P99 from ~1.6s to 28,381ms, sustained). Detection surfaced the anomaly with deviation badges and the blast radius on the cloud graph (checkout-edge, hd-prod, payments-db on PlanetScale, cart-svc, edge-gateway). The investigation thread correlated the change record, and autofix opened pull request #142 restoring max_connections to 50, with a regression test.

## Product capabilities (full)

### The cloud graph

Nobody remembers how production is actually wired. Your code and cloud in one live, greppable graph, with a wiki that rewrites itself as the system drifts.

### Anomalies

No thresholds to tune. An agent reads the actual series and decides, the way you would at 3am.

### Change intelligence

Most incidents start with a change. Every sync records exactly what changed, and agents check that first.

### Threads and incidents

Every run is a transcript you can watch, interrupt, and share, with every number cited back to its source.

### Automations

Describe the job in plain English. Polylane builds the trigger, the instructions, and the allowed actions.

### Skills

Typing the same investigation prompt a third time? Make it a skill. Fix it once, every caller inherits the fix.

### Autofix

Investigations that end at a line of code end as a pull request. Your review and CI still gate the merge.

### Every surface

Console, CLI, API: one platform. The CLI is built for coding agents, and Cmd+. puts the agent on any browser tab.

## Roadmap (full)

### The cloud graph

- [done] **One graph, every cloud**: Connect AWS, Cloudflare, Vercel, Fly, and Render, and every resource you run lands in a single living graph with its edges, config, and history.
- [done] **Kubernetes**: Clusters, workloads, and their churn alongside everything else. Hand us a kubeconfig and EKS wires itself up.
- [done] **Wikis that write themselves**: Every cloud resource gets living documentation that rewrites itself as your system drifts, and your repositories are indexed for agents to grep.
- [done] **Change intelligence**: Every sync writes down exactly what appeared, changed, or disappeared. When production breaks, the culprit is usually in here.
- [done] **Blast radius**: Every anomaly maps the slice of the graph it touches, and the investigation starts from that map: agents walk the affected edges to the offending resource instead of guessing.
- [done] **Resource tiers**: An agent ranks every resource by how load-bearing it is. Tier one gets watched closest and investigated first, and you can overrule the ranking anytime.
- [planned] **Applications**: Resources grouped into the applications they serve, so agents know what's load-bearing before they touch anything.
- [planned] **More clouds**: GCP, Azure, Supabase, Railway, and DigitalOcean. Same graph, same treatment.

### Detection without thresholds

- [done] **Proactive observability**: Agents comb your metrics, logs, traces, and access logs on a cadence and flag what's actually wrong, before your customers do. No thresholds to tune, no alert rules to babysit.
- [done] **Observability providers as sources**: Datadog, Sentry, Honeycomb, and Axiom join the graph as first-class citizens, and an agent triages every alert they fire the moment it lands.
- [done] **Your charts become checks**: That dashboard your team curated? Every query and chart saved in a provider gets picked up on the next sync and watched from then on.
- [done] **Déjà vu detection**: Repeat detections fold into one anomaly instead of re-paging you. An 18x P99 regression is one anomaly, not forty pages.
- [done] **Scan reports**: Ask for a sweep of a whole account and an agent walks the graph, queries the telemetry, and hands you a written report of what it found.
- [in progress] **Telemetry attribution**: Logs, metrics, and datasets from your observability providers matched to the exact resources that emit them. No tagging homework, an agent works out the mapping.
- [in progress] **Vercel runtime telemetry**: Function logs and runtime metrics from Vercel joining the graph, next to the deployments and domains we already sync.
- [planned] **Cloud doctor**: Like react-doctor, for your cloud. One command grades the whole account: misconfigurations, missing observability, security posture, and the five things to fix first.
- [planned] **Cost intelligence**: Billing joined to the graph, and agents that point at exactly which resources are burning money for nothing.
- [planned] **More providers**: Grafana, Splunk, Better Stack, SigNoz, and Logfire, with the same first-class treatment.
- [planned] **Closing the loop with product**: PostHog, Mixpanel, and Amplitude in the graph, so an incident's blast radius includes what your users actually felt.

### From signal to reviewed fix

- [done] **Incident threads**: Every investigation is a transcript with cited tool calls. Watch it think, interrupt it, hand it to a teammate, or make it public.
- [in progress] **Marathon investigations**: The agent loop is moving onto durable workflows: investigations that grind for hours, survive restarts, and pick up exactly where they left off.
- [done] **Autofix**: Investigations that end at a line of code end as a pull request, with a regression test and the evidence trail. You review, you merge.
- [done] **Bring your own executor**: Route autofix through Cursor or Devin with your own key, or let the built-in agent open the PR.
- [in progress] **The next autofix engine**: The built-in executor is moving to the open-source pi coding agent, running in the same sandbox with the same review gates.
- [planned] **More executors**: Claude Code, Codex, and Factory: delegate the fix to whichever agent your team already trusts.
- [done] **Memory**: Agents remember what they confirm; so can you. Each day the workspace also writes its own notes from your threads, durable facts plus a daily log, so every investigation starts already knowing your system.
- [done] **Skills**: The way your team debugs, packaged into procedures agents reach for on the next incident. Write them once, benefit every time.
- [planned] **Dynamic skills**: Agents notice what keeps working and write their own skills, sharpening them with every incident.
- [done] **Automations**: Cron, webhooks, GitHub events, and alerts trigger agent runs; results land in email, Slack, or your webhook.
- [done] **Advisories**: Every resource carries its misconfigurations and risks, each one marked fixable in place or with guidance.
- [planned] **Agents on your pull requests**: A comment when a change looks like tomorrow's incident, an answer when you ask whether it'll break production.
- [planned] **Change intelligence for pull requests**: Every PR annotated with what it will actually change in your cloud, before you merge instead of after the deploy.
- [planned] **Issue trackers**: Findings filed as issues in Linear or Jira, where your team already plans work.

### Every surface

- [done] **A CLI built for coding agents**: Structured output, non-interactive flags everywhere, and a skill that teaches Claude Code or Cursor when to reach for it.
- [done] **MCP server**: The whole platform as tools for any agent that speaks MCP.
- [done] **Bring your own MCP**: Connect your own MCP servers and their tools show up in the agent's hands mid-investigation.
- [done] **Public API**: Everything the console does, scriptable.
- [done] **Slack**: Notifications where your team lives, and investigations you can spin off from any message.
- [in progress] **Browser extension**: Cmd+. puts the agent on whatever tab you're reading; the page becomes the thread's context.
- [planned] **Your incident platforms**: An incident fires in PagerDuty or incident.io and an agent is already investigating before anyone picks up the page. Resolved with evidence, not just acknowledged.

## Blog posts (full content)

### I'm Betting My Company on Proactive Agents

URL: https://polylane.com/blog/proactive-agents/
Date: Jul 5, 2026
Author: Boris Tane
Description: Agents can do almost anything you ask. That's the problem, you still have to ask. The next evolution is agents that figure out the job to be done. I started with operations, because nobody should be on-call in 2026.

import PromptBox from "../../components/blog/PromptBox.astro";
import CliBox from "../../components/blog/CliBox.astro";
import AutomationCard from "../../components/blog/AutomationCard.astro";
import PullRequestCard from "../../components/blog/PullRequestCard.astro";

Agents can do almost anything you ask them to, and that's the problem: **you still have to ask**.

I keep hearing people call agents "digital coworkers". That framing is wrong. A coworker who sits in silence until you hand them a perfectly-scoped task, completes it, then goes back to waiting, is not a coworker. Every agent you've ever used works exactly like this. The models got smarter, the harnesses got better, the runs got longer, but the interface never changed: you bring the work, the agent brings the labour.

And most people haven't noticed, because the prompt box has quietly become what AI *is* in our heads.

<PromptBox caption="The default interface of AI." />

## Every interface is still a prompt box

The input box is how this whole era started. ChatGPT put one on top of a model and became the fastest-growing product in history, and we all copied it. Every AI product since has been a variation on the same interaction: human types, machine responds, machine waits.

Claude Code was the next evolution. The agent moved into your terminal, picked up your files, your shell, and your git history, and started doing real work instead of talking about it. It changed what agents could do, but not how they start: you type, it works, it stops, and it waits for you to type again.

<CliBox caption="The same input box, in a terminal." />

Then agents moved to the cloud. Codex, Devin, Claude Code on the web. They run for hours instead of minutes, spin up sub-agents to parallelise the work, and don't die when you close your laptop. You hand one a task before lunch and come back to a pull request.

```mermaid
graph TD
    A[You write the task] --> B[Cloud agent]
    B --> C[Sub-agent]
    B --> D[Sub-agent]
    B --> E[Sub-agent]
    C --> F[Pull request]
    D --> F
    E --> F
    style F fill:#d1fae5,stroke:#6ee7b7,color:#065f46
```

The prompt even stopped being a keyboard-only thing. Background agents can be kicked off by an alert or a webhook, and most agent platforms now offer automations: when this event fires, or this cron ticks, run an agent with these instructions.

<AutomationCard caption="An automation: the agent acts on an event, following instructions you wrote." />

But what is an automation? It's **a prompt you wrote in advance**. You predicted the failure mode, picked the event, and wrote down what to do about it. The trigger fires the agent, but the judgement inside it is yours, frozen at setup time. An automation catches exactly what you anticipated, and nothing else.

## You are the scheduler

Strip away the tooling and the division of labour hasn't moved in three years. The agent does the work. Deciding what the work is remains your job.

You read the dashboards, you listen to the users, you figure out what matters, and you compress everything you've learned into a prompt, either live at the keyboard or ahead of time in a trigger. The agent executes brilliantly, but every piece of judgement in the system originates with you.

```mermaid
graph TD
    A[Dashboards] --> D[You]
    B[Alerts] --> D
    C[User complaints] --> D
    D --> E[The prompt you type today]
    D --> F[The automation you configured last month]
    E --> G[Agent]
    F --> G
    style D fill:#fee2e2,stroke:#fca5a5,color:#991b1b
```

## The next evolution: agents that find the work

I'm betting the next evolution is agents figuring out the job to be done. No prompt, no trigger to configure, no instructions written in advance. You connect your stack, and the agent finds the work by itself: it watches the same signals you watch, notices what's off, decides whether it matters, and starts working on it autonomously.

This is easy to say, and brutally hard to build, because proactivity is three problems stacked on top of each other, and skipping any one of them gives you something worse than the agent behind an input box.

**Context.** Obviously, the agent needs a live model of the world it operates in, not a snapshot you pasted into the context window at prompt time. A reactive agent with bad context gives you a bad answer. A proactive agent with bad context drops your prod database because it thought it was staging.

**Judgement.** This is what has been giving me the hardest time. At any given moment, thousands of things in a production system are slightly off. An agent that flags all of them is a noise machine, noise machines get muted, and muted agents are dead agents. The entire value of proactivity lives in the gap between "something changed" and "something matters":

```json [triage-verdicts.json]
[
  {
    "signal": "memory up 3% on checkout-edge",
    "verdict": "no anomaly",
    "reasoning": "within the seasonal range for this hour on this worker"
  },
  {
    "signal": "new error pattern, 2 minutes after deploy 9f3c2a1",
    "verdict": "incident",
    "reasoning": "error class never seen on this worker, tightly correlated with a deploy"
  }
]
```

**Action.** Noticing without acting is just a smarter alert, and alerts are the thing I'm trying to kill. The agent has to finish the job, inside boundaries that make autonomy safe: reversible actions, receipts for everything, and a hard gate before anything irreversible happens.

None of these three involve the agent deciding **what good looks like**. It decides what's off, whether it matters, and what to do about it, and that's the whole list, because in production nobody has to define good: errors at zero, latency at baseline, queues drained, certificates valid. The desired state comes with the territory.

Which means the real shift isn't from "you prompt" to "the agent prompts itself". It's from **imperative operations to declarative operations**. An automation is imperative: you enumerate the failure modes in advance and script a response to each. A proactive agent is a reconciliation loop: it holds the system you have up against the system you should have, and works to close the gap. Kubernetes did this for infrastructure a decade ago, you write down three replicas and a controller does whatever it takes to keep three replicas alive. Nobody has done it for the operation of software itself. And here there isn't even YAML to write, because the desired state is already known. It works out of the box.

## I started with operations

Ask a proactive agent to pick your product roadmap and you get an opinionated intern, because product direction is a matter of taste. Production isn't. It's the one domain where all three problems are solvable today.

The work announces itself: error rates climb, a deploy goes sideways, a certificate expires, a queue backs up. The work is already sitting in the telemetry, waiting for someone to notice it. And unlike taste-driven domains, ground truth exists: the error rate either spiked or it didn't, the rollback either restored the baseline or it didn't, so the agent's judgement gets scored by the system itself, continuously, with no room for vibes.

Most of all, we already staff this job with humans. We call it *on-call*: a person sleeping next to a phone, waiting for a machine to say that another machine is unhappy. I spent years in observability, founded an observability company and Cloudflare acquired it, and wrote a whole [manifesto](https://loggingsucks.com) about structuring telemetry so the answer is one query away. Its thesis is the reason this company exists: **nobody should be on-call in 2026**.

Because the uncomfortable truth about the last decade of observability is that we made systems easier for humans to interrogate at 3am, then declared victory while humans were still the ones being woken up. The dashboards got prettier and the pager stayed on the nightstand. Observability without action is just expensive storage.

## What it looks like

This is what [Polylane](https://polylane.com) does. Here is a concrete Tuesday:

```mermaid
graph TD
    A["02:14 — checkout p99 jumps from 180ms to 2.1s"] --> B["02:15 — agent flags it: new error pattern, right after the 01:52 deploy"]
    B --> C["02:16 — incident opens, 3 hypotheses investigated in parallel"]
    C --> D["02:31 — verdict: connection pool exhausted by a new N+1 query"]
    D --> R["02:33 — the 01:52 deploy is rolled back, p99 back to 180ms. The incident is over."]
    R --> E["02:38 — PR opened with the fix and the evidence attached"]
    E --> F["08:30 — you wake up, read the investigation, merge"]
    style A fill:#fee2e2,stroke:#fca5a5,color:#991b1b
    style R fill:#d1fae5,stroke:#6ee7b7,color:#065f46
    style E fill:#d1fae5,stroke:#6ee7b7,color:#065f46
```

Nobody configured a check for this failure mode. There are no rules to write and no thresholds to tune: agents evaluate every connected resource on a continuous cadence, and your existing dashboards and saved queries become their checklist. Judgement is where I am strictest. The default verdict is *no anomaly*, because it's much better to miss a borderline issue than to wake someone for noise. "A deploy could introduce a bug" is true of every deploy and never grounds to page anyone.

When something is real, the investigation runs several competing hypotheses in parallel, and each agent's job is to disprove its hypothesis rather than confirm it, so correlation never gets to masquerade as cause. When the confirmed root cause is a code change, the fix arrives as a pull request with the investigation attached:

<PullRequestCard caption="The fix arrives as a PR. You review, it merges." />

## Proactive is not unsupervised

The autonomy is in the noticing, the triage, the 3am archaeology, and the mitigation. Anything that restores a known-good state, the agent does on its own: roll back the bad deploy, flip the flag back off. Those actions are reversible by construction, and they are the ones that actually silence the pager. What stays gated is anything that creates a new state: a code change ships through your review and your CI, never around them.

The line isn't human versus agent. It's **reversible versus not**. And it's why you're not secretly still on-call: the rollback ended the incident at 02:33, six hours before you merged the pull request. The PR was never what stopped the bleeding. It's what stops it from happening again, and that can wait for coffee.

And the gate is yours to delegate. Code review agents already read every pull request in your repo. There is a world, not far from this one, where your review agent reads the fix at 02:41, checks it against the investigation, approves it, and your CI deploys to production before you wake up. Nothing about the loop changes except who holds the approve button. That is where this ends: **software that fixes itself**, with you writing the policy instead of clicking merge.

```mermaid
graph TD
    A[Signals] --> B[Detection]
    B --> C[Investigation]
    C --> R[Rollback, on its own]
    C --> D[Pull request]
    D --> E[You or your agent review, it merges]
    R --> F[Memory]
    E --> F
    F --> B
    style R fill:#d1fae5,stroke:#6ee7b7,color:#065f46
    style D fill:#d1fae5,stroke:#6ee7b7,color:#065f46
    style F fill:#dbeafe,stroke:#93c5fd,color:#1e40af
```

Notice what's missing from that loop:

<PromptBox dimmed caption="Nobody typed anything. Nobody configured anything." />

The prompt box was a great way to learn to trust these systems, and it's a terrible way to run production. The agent has seen every deploy, every log line, and every metric across every service at once. Keeping it behind a prompt means the best-informed member of your team only speaks when spoken to.

Nobody should be on-call in 2026.

## Build log (full content)

### July 3, 2026

URL: https://polylane.com/build-log#2026-07-03

Scans grew up this week. A scan used to be a throwaway result you watched scroll by; it's now a report with its own URL. There's a scans page with filtering and bulk actions, live progress while a scan runs, topology and starter questions when it lands, and a public share link when you want to show someone outside your workspace. It works on cloud accounts and on your Datadog, Honeycomb, Axiom, and Sentry integrations.

The feed got the same treatment. It now opens with a 30-day summary of what Polylane actually did for you (issues caught, changes that caused issues, autofix PRs, anomalies resolved, each with a sparkline), a health score, and a "waiting on you" table of the decisions that need a human. And under the hood, incident threads moved onto durable workflows, so investigations survive deploys and restarts, and the built-in autofix executor now runs the open-source pi coding agent, with the full transcript readable behind every PR.

Also this week:

- Sentry alert-rule and issue webhooks now open incidents: triaged by an agent the moment they arrive, with status and verdict badges and a one-click investigate
- Recurring anomalies keep the metrics, logs, and traces captured at every occurrence, browsable newest-first, instead of only the latest
- Anomaly pages lead with sparkline metric cards showing value, baseline, and deviation, a blast-radius view, and a log summary
- Change history per resource: change signals on every node's detail panel, and top-changed resources surfaced in the feed
- Advisories are computed on the backend, each one marked fixable in place or with guidance
- Thread reliability: stale turns are swept automatically, model capacity issues fall back gracefully, and runaway turns get cut off instead of spinning
- And as always: reliability, performance, and stability improvements

---

### June 26, 2026

URL: https://polylane.com/build-log#2026-06-26

Nobody wants a thousand raw log lines dumped into the middle of an investigation. This week every telemetry query the agents run (CloudWatch, Datadog, Honeycomb, Axiom, Sentry, Cloudflare, Vercel, Fly, Render, X-Ray) gained a summary mode: the full, untruncated result gets distilled into severity, error counts, recurring patterns, and the handful of lines actually worth reading, quoted verbatim. Threads stay readable, and the agent stops drowning its own context in logs.

Connecting an account got better too. A first scan now produces a structured report of ranked risks, key metrics, and log and trace digests, with starter questions to dig in. And for Cloudflare, a new modal pre-fills every permission Polylane needs and lets you choose between read-only (investigate and explain only; changes only ever land as PRs) and full access, so nobody has to hand-pick API token permissions again.

Also this week:

- Resource tiers re-classify automatically every day, and you can now override any resource's tier by hand (overrides are pinned) or re-run classification for a whole account
- Every anomaly gets a one-click investigate that opens an incident thread, with dedupe so the same anomaly never spawns duplicates
- AI-suggested starter questions now appear on changes, check-run evaluations, and individual resources, not just after connecting
- `polylane automation create` and `POST /automations` accept custom triggers, instructions, and tools, so you can build automations no template covers
- A check-run slideover to inspect a single evaluation's metrics, logs, and traces, with investigate and question actions inline
- Per-resource monitoring now gathers structured evidence: top and new log templates, severity totals, error and fault rates, and p50/p95/p99 per operation
- One-click repair for broken Mermaid diagrams in resource wikis
- And as always: reliability, performance, and stability improvements

---

### June 19, 2026

URL: https://polylane.com/build-log#2026-06-19

Connecting an account finally has a proper moment. Instead of dropping you back on a dashboard, Polylane now lands you on a page that explains what it can see in the account you just connected, kicks off a first scan, and offers three tailored questions worth asking the agent. The first five minutes went from "now what?" to an actual conversation about your infrastructure.

The other theme this week is trust. When an agent wants to perform a mutating action, the thread now shows you the method, path, body, and reason, and waits for your approval, with deletes flagged as destructive. And every incident now declares where it stands at the end of each agent turn (needs human action, needs a decision, awaiting a change, failed, or resolved), so you can tell at a glance which investigations actually need you.

Also this week:

- Every monitoring pass is recorded as a check run (healthy, breached, or stable), giving each resource a timeline of evaluations you can inspect, plus a manual trigger
- Resources are automatically classified into tiers 1–4 by operational criticality, using topology, traffic, and recent changes; tiers now drive how anomalies are prioritised
- AWS sync gained Kinesis, KMS, Secrets Manager, and Service Discovery
- You can discover and link GitHub repositories to a cloud account, tying the code to the infra it runs
- Rate limiting and request coalescing landed across every provider client, so investigations stop getting throttled by provider APIs
- Change intelligence now maps provider change events to the specific resources they touched, rendered in the feed
- A rolling 24-hour view of incident usage against your workspace limits
- And as always: reliability, performance, and stability improvements

---

### June 12, 2026

URL: https://polylane.com/build-log#2026-06-12

Autofix opened up this week. You can now connect Cursor and route autofix pull requests through its cloud agents instead of the built-in one: when an investigation ends at a line of code, Polylane hands off the fix and Cursor opens the PR. Pick a default executor per workspace in Settings → Integrations.

Automations got easier to start with, too. There's now a catalog of pre-built templates, with the trigger, agent instructions, and actions already wired, installable in one step from the console, the CLI (`polylane automation from-template`), or the API. Templates are filterable by category and provider, and only enable actions for providers you've actually connected. Alongside it, new triage controls give you a master switch plus per-alert-rule toggles on every cloud account and integration, so you decide exactly which alerts Polylane picks up and investigates.

Also this week:

- Much broader Cloudflare coverage in the graph: zones, load balancing, WAF and security rulesets, Tunnels, Spectrum, Access, Stream, Images, and more Workers resources
- Cross-cloud edges: a DNS record on one provider pointing at a resource on another now shows up as a real edge in the graph
- Quieter anomaly detection: a deterministic backstop drops isolated spikes and near-zero-baseline noise before triage, detection respects which direction is actually bad per metric, and change-record anomalies dedupe within 24 hours instead of re-paging
- The Changes tab shows impact at a glance: an impact badge, risks, post-change verification, and affected resources as chips
- Custom LLM endpoints now list the models they actually advertise, so you pick from real models instead of typing IDs
- OAuth client secrets can be rotated without recreating the client
- And as always: reliability, performance, and stability improvements

## Open roles (full content)

### Founding Growth

URL: https://polylane.com/careers/founding-growth/
Location: San Francisco, CA
Type: Full-time, in-person
Compensation: $200k to $400k + meaningful equity
Apply: POST https://polylane.com/api/careers/apply with {"jobId": "founding-growth", "email": ..., "link": ..., "location": ...}

## Opportunity

Coding agents now write most of the code. The bottleneck has moved from typing to everything around it: observing, monitoring, debugging, root-causing, on-call, deciding what's safe to ship. The lifecycle is collapsing into two halves. One half is intent. The other is execution. The execution half should not be as hard.

We're building Polylane: the platform that lets developers ship self-operating software. Software that watches itself in production, investigates anomalies, finds root causes, and ships fixes before anyone gets paged. Software that operates itself.

Someone has to make sure every developer on earth hears about it. That's this role: growth built as a software system, not a spreadsheet, owning the loop from a developer hearing about Polylane to a workspace with a connected cloud.

## What you'd work on

- Owning the self-serve funnel end to end: waitlist, onboarding, activation, and the instrumentation that tells us what's working.
- Building the content engine: docs, changelogs, technical posts, and the tooling that makes publishing fast.
- Shipping growth experiments weekly and killing the ones that don't move anything.
- Building distribution surfaces: integrations, templates, CLI install flows, and the places developers discover tools.
- Turning product moments into shareable artifacts, the way an incident investigation becomes a story worth posting.

## What we're looking for

You should be a strong full-stack engineer who has owned growth, activation, or developer experience before. This is an engineering role with growth instincts, not a marketing role with a code editor. You write TypeScript fluently and ship fast: prototype, iterate, throw it out when it doesn't work.

You think in funnels and cohorts, and you instrument before you argue. You write well; developer marketing is mostly writing that respects the reader.

Taste is especially helpful here: for what developers actually share, for prose, for what makes a tool feel right under a developer's hands. And an allergy to what they scroll past.

## Who is Coreplane Labs?

A small team, and the company behind Polylane. We've operated at Cloudflare scale, where we built the observability platform used by millions of developers every day. We've spent years writing, operating, and breaking production systems for a living.

Coreplane is what comes next. Based in San Francisco. We work in person.

---

### Founding Engineer

URL: https://polylane.com/careers/founding-engineer/
Location: San Francisco, CA
Type: Full-time, in-person
Compensation: $200k to $400k + meaningful equity
Apply: POST https://polylane.com/api/careers/apply with {"jobId": "founding-engineer", "email": ..., "link": ..., "location": ...}

## Opportunity

Coding agents now write most of the code. The bottleneck has moved from typing to everything around it: observing, monitoring, debugging, root-causing, on-call, deciding what's safe to ship. The lifecycle is collapsing into two halves. One half is intent. The other is execution. The execution half should not be as hard.

We're building Polylane: the platform that lets developers ship self-operating software. Software that watches itself in production, investigates anomalies, finds root causes, and ships fixes before anyone gets paged. Software that operates itself.

This is what comes after coding agents. The boring parts of software engineering, automated end-to-end. The development lifecycle for a world where humans set intent and software does the rest.

## What you'd work on

- Building agents that observe, reason about, and act on production systems end to end.
- Turning raw telemetry, code, and infrastructure into context a model can actually reason from.
- Designing operator interfaces that make autonomous software feel obvious to humans and legible to other agents.
- Working across the stack from product, design, and platform to get features into production quickly.
- Closing the loop between what we observe in production and the code an agent writes next.

## What we're looking for

You should have strong product engineering instincts and be comfortable owning features end to end. You write TypeScript fluently and ship fast: prototype, iterate, throw it out when it doesn't work.

You've built agentic systems with modern frameworks and have opinions about what works. You've operated production systems and understand observability deeply: traces, wide events, high-cardinality data.

Experience with the Cloudflare developer platform (Workers, Durable Objects, R2, D1, Queues), ClickHouse, or other infrastructure-adjacent products is especially helpful. So is taste, for product, for prose, for what makes a tool feel right under a developer's hands.

## Who is Coreplane Labs?

A small team, and the company behind Polylane. We've operated at Cloudflare scale, where we built the observability platform used by millions of developers every day. We've spent years writing, operating, and breaking production systems for a living.

Coreplane is what comes next. Based in San Francisco. We work in person.

---

### Founding Researcher

URL: https://polylane.com/careers/founding-researcher/
Location: San Francisco, CA
Type: Full-time, in-person
Compensation: $200k to $400k + meaningful equity
Apply: POST https://polylane.com/api/careers/apply with {"jobId": "founding-researcher", "email": ..., "link": ..., "location": ...}

## Opportunity

Coding agents now write most of the code. The bottleneck has moved from typing to everything around it: observing, monitoring, debugging, root-causing, on-call, deciding what's safe to ship. The lifecycle is collapsing into two halves. One half is intent. The other is execution. The execution half should not be as hard.

We're building Polylane: the platform that lets developers ship self-operating software. Software that watches itself in production, investigates anomalies, finds root causes, and ships fixes before anyone gets paged. Software that operates itself.

None of that works unless the agents are trustworthy. This role's goal is to improve the models and the harnesses behind self-operating software. The hard problem is not getting a model to propose a fix; it is knowing, empirically, when the agent is right, when it is guessing, and how to move that boundary run after run. This is research in production: your experiments ship to real workspaces, and the feedback loop is measured in days, not conference cycles.

## What you'd work on

- Improving the models themselves: post-training on real operational data so they investigate production systems better with every run.
- Improving the harness: the agent loop, the tools, and the context, so the same model gets further on the same incident.
- Building evaluation harnesses that score agent investigations against ground truth from real production incidents.
- Running context engineering experiments: what to inject, when, and how much, across briefings, memory, and retrieval.
- Studying failure modes of tool-using agents on long-horizon operational tasks and turning them into fixes.
- Publishing internally, and externally when it makes us sharper.

## What we're looking for

You should have shipped LLM systems and measured them seriously, beyond demos and vibes. You're fluent in evaluation methodology: building datasets, defining metrics, avoiding contamination.

You write production-quality code in TypeScript or Python and don't need a research engineer to ship. You have opinions about agent reliability, grounding, and context windows, backed by experiments.

You're comfortable when the answer is "we don't know yet" and rigorous about finding out.

## Who is Coreplane Labs?

A small team, and the company behind Polylane. We've operated at Cloudflare scale, where we built the observability platform used by millions of developers every day. We've spent years writing, operating, and breaking production systems for a living.

Coreplane is what comes next. Based in San Francisco. We work in person.

## Values

- We ship skateboards. The first version rolls, it doesn't fly. We'd rather put something real under people this week than promise a car next quarter.
- Make every single detail perfect, and limit the number of details. Fewer things, obsessed over. If a detail isn't worth perfecting, it doesn't ship.

## Contact

- X: https://x.com/polylanehq
- Email: boris@coreplane.ai

## Citation

When referencing Polylane, cite as: "Polylane (polylane.com), the automation platform for modern infrastructure, by Coreplane Labs."