Questions CTOs & Engineering Teams Ask

Not by default. Every task runs in its own isolated workspace with no shared compute, and agents only ever touch code on a branch — never main, never a live or deployed system — unless your team has a need to enable such mechanisms.

Every PR is scored by an AI review jury that produces a merge-confidence rating — an independent check, not the coding agent’s own self-assessment. If auto-merge is enabled for your repo, high-confidence, low-risk PRs merge automatically once CI is green and no blocking label is present; otherwise (or if a PR falls below the threshold), a human reviews and approves it before it ships. Everything is logged either way.

No. We don’t train models on your code or your session data — this isn’t a setting you have to find and enable, it’s simply how the platform works today. We also choose our providers carefully to maintain zero data retention policy, so your code and session data aren’t retained on their end either.

Yes. Each connected repository has its own configuration — egress rules, resource limits, secret access, whether auto-merge is enabled, what triggers a session — enforced at the infrastructure level, not by asking the agent nicely to follow different rules. Your payments service and your internal tooling repo can run under entirely different policies.

Yes. Nothing about how Dap connects to a repository requires an org-wide rollout on day one — policies are set per repository, so starting with a single team’s codebase and expanding once you’re comfortable is the normal path, not a special accommodation.

Claude Code and Codex are both supported today. Grok is coming soon — same workspace-native experience. Need something else? Tell us; adding support for another subscription is usually straightforward.

What’s built into Dap came from patterns across years of delivery work — how to structure agent workflows, what governance actually needs to look like — not from your specific code or business logic. Your codebase, your data, and your competitive specifics stay yours; the operational lessons that shape how Dap works are a different thing entirely.

Your code, always — every PR lands in your own repository, so nothing about ending the engagement changes what’s already shipped there. Dap documents its reasoning directly into each PR as it happens — every decision and file change tied back to the ticket — so that context stays with your repo permanently, not locked away in a separate system.

Yes. Your own engineers can drive Dap’s day-to-day use — either alongside Crunchloop’s dedicated engineers, or on their own. Either way, Crunchloop still deploys and manages Dap itself, through our Forward Deployed Engineers. Let us know, and we’ll walk you through how that’s set up.

Not today. Dap isn’t sold as standalone software — we believe Crunchloop and Dap still work better hand in hand. We’ll see what the future holds.

We’re opinionated about how software pricing should work going forward — see our take on what actually holds up, and the principles behind it, on the Pricing page.

No. Dap keeps its own inference light enough that costs aren’t affected by subscriptions. Unattended sessions are a different story — they can’t run on a subscription at all, which is exactly why Dap has its own separate pricing mechanism for that kind of work.

Let us know if you need this — we’re working on ways to make that possible, but the docs aren’t publicly available yet.

Our public materials don’t currently confirm a SOC 2 or equivalent certification. If that’s a hard requirement for your organization, tell us — it shapes what we prioritize next.