OpenScaffold

Forward deployed engineers, solutions engineers, implementation engineers and deployment leads working on enterprise rollouts have to track customer requirements scattered across kickoff calls, emails, Slack threads and tickets, things like deadlines, data residency rules, approval thresholds and state-specific regulations. Today a coding agent has no memory of what the CISO said on a call or what the VP of Claims required in an email, so it can write code that violates a customer's stated rules, such as moving claimant data out of a required VPC. When one deployment ends, the lessons learned, runbooks, environment quirks and domain notes often leave with the engineer instead of being handed to the next deployment. This creates repeated mistakes, rework, and risk of breaking explicit customer commitments.

OpenScaffold builds a three layer scaffold around each deployment. The first layer, the deployment model, turns calls, emails and tickets into a set of goals, rules and asks that are only accepted if quoted word for word from the source, with conflicting updates (like a later procurement email contradicting a CISO's VPC requirement) flagged for human decision rather than applied automatically. The second layer, the frame, briefs every coding agent session (works over MCP with Claude Code, Cursor, Codex, VS Code and cloud agents) on the customer's goals and rules, lets the agent look up the customer's own words mid-session, blocks code changes that break a verified rule, and reports back what was built for approval. The third layer turns what agents learn into playbooks, stripped of customer data by a 'leak guard' that removes customer names, systems and copied phrasing, so environments, runbooks, evals and domain notes carry forward to the next deployment. The product connects to Gmail, Drive, Slack, Linear, Jira, Confluence and GitHub to build the deployment model automatically from what comes in.