Platform Engineer

About the Role

Dedalus Labs builds persistent computers for AI agents. Our flagship product, Dedalus Machines, gives agents an isolated environment where they can run software, keep files and state, and work over time.

You'll own the internal platform engineers use to build, test, release, and operate our software. Your focus is CI/CD, GitHub Actions, build systems, release pipelines, and observability. A source change should move through a reliable pipeline, and a production failure should lead us to the relevant request, resource, release, and evidence.

You'll work across a large, fast-moving codebase to remove slow feedback, manual release steps, and gaps in visibility. Success means engineers ship safely with less coordination and can turn platform telemetry into concrete fixes.

What You'll Work on

• Build and CI infrastructure.
• Own GitHub Actions workflows, runners, test execution, build caching, and artifact storage.
• Reduce queue time, repeated work, flaky failures, and local/CI differences.
• Measure build latency and reliability as the codebase grows.

Our open-source tooling includes Bessemer (BSMR) our build system, and Hollywood which generates GitHub Actions from typed TypeScript definitions and runs actions locally. Improve the tools themselves when their behavior limits the development workflow.

• Release engineering.
• Build repeatable pipelines for artifact publishing, staging validation, promotion, production rollout, and rollback.
• Connect every running version to its source, build inputs, and tested artifact.
• Make failed releases diagnosable and recovery procedures testable.

• Platform observability.
• Build consistent instrumentation across services and infrastructure.
• Correlate logs, metrics, traces, errors, and release events so engineers can follow an operation end to end.
• Turn that data into useful queries, dashboards, alerts, and investigations that identify regressions, bottlenecks, and affected users.

• Efficient telemetry ingestion.
• Design and operate collectors and ingestion pipelines.
• Handle batching, buffering, retries, and backpressure, and detect delayed or dropped data.
• Manage sampling, retention, and metric cardinality so useful coverage scales without uncontrolled cost or lost diagnostic evidence.

• Developer environments.
• Automate local setup and test environments, maintain shared tooling, and make common operations repeatable.
• Use containers, Kubernetes, and infrastructure as code where they support reliable development and delivery.

You'd Be a Good Fit If

• You treat other engineers as users. You investigate where their workflow breaks down, implement a fix, and follow through until they can use and troubleshoot it.
• You can follow a failed build, release, or request across tools and services. You collect evidence, distinguish symptoms from causes, and make the next investigation easier.
• You choose tests that establish the right guarantees, verify performance changes against a baseline, and explain the limits of the result. You can make a scoped improvement and ship it.
• You communicate decisions clearly, act on feedback, and own the reliability of what you build. You can use AI tools and take responsibility for the resulting code.

Experience That Helps

You have built or operated CI/CD, release infrastructure, developer tooling, or observability systems that other engineers rely on. You can write and debug software in TypeScript, Python, Go, Rust, or a similar language, and investigate failures on Linux.

GitHub Actions and release-pipeline experience are especially relevant. Build systems such as Buck2, Bazel, or Blaze, remote execution, and cache design are useful. For observability, experience with Grafana, Datadog, Sentry, OpenTelemetry, or similar tools should include instrumentation, ingestion, and using the data to make engineering decisions.

Experience at a big tech company or on another large, fast-moving codebase is a plus, not a requirement. We value what it taught you about code review, shared tooling, release discipline, and making changes other engineers can trust.

• Show depth in one or more of these areas and the ability to learn the others.
• Explain the workload, scale, failure modes, and changes you personally owned.
• A degree, particular employer, or experience with every tool above is not required.

This Role May Be a Poor Fit If

• You are satisfied with a green pipeline or a dashboard without checking whether it helps engineers release safely or diagnose failures.
• You routinely accept flaky builds, manual release steps, or noisy alerts without investigating their cause.
• You keep polishing after the agreed deadline or claim an improvement without measuring it.

Pay and benefits

This is a full-time, in-person role in San Francisco. The annual base salary range is $120,000-$250,000 USD, depending on relevant experience and role scope. Relocation assistance and visa sponsorship are available.

Show US Your Work

Use your application to show us one thing you built and one difficult problem you investigated. They can come from the same project. Choose work you already have. We are not asking you to build a new project for this application.

• Work: Show the code, demo, design, or result. Explain what you personally owned, what you reused, and one decision that made the result better or simpler.
• Investigation: Describe the symptom, your first explanation, the evidence that changed your thinking, and how you established the result. Include the workload or users involved and any important limitations.
• Writing: Share one piece of writing you care about as a separate, required sample. Any medium or length is welcome. Tell us why you wrote it, who it was for, and what you wanted to communicate. Looking back, what works well and what would you change? We care about the quality of your thinking and writing, and your reflection on the work. Link it or paste a redacted excerpt. Explain your contribution and any coauthors or AI assistance.

Work from employment, open source, research, coursework, or independent projects is welcome. Public source code is optional. A redacted excerpt or a concrete account of private work is fine. Keep confidential information out of your application.

Tell us which problem in this role you want to own and why. If your strongest evidence is easy to miss on a resume, point us to it. An existing demo or short screen recording is welcome, and video is optional.

Useful examples include a faster build, a release pipeline you made reliable, or telemetry that exposed a previously hard-to-diagnose failure. Explain the before and after, your contribution, and how other engineers used the result.