The AI workspace for hardware teams

Adam edits through your CAD file the way a careful teammate would, adjusting a dimension, adding a feature, or mating a component while respecting the existing history and references. It regenerates the model, shows you which downstream features and BOM lines changed, and flags any edit that would break a parent-child relationship instead of forcing a rebuild.

Adam reads your assembly and PLM (Arena and others) and keeps the BOM in sync as the model changes, flagging part-number, quantity, and revision mismatches instead of silently editing released data. When something changes it drafts the ECO, cross-referenced to the edit that caused it.

Your geometry, drawings, BOMs, and correspondence stay in your own accounts and PLM. Adam connects over scoped, authenticated access (OAuth where supported) and reads only what a task needs, never copying your CAD into a separate store. Nothing you connect trains models, nothing is shared between accounts, and every workspace is isolated and encrypted. Enterprise plans add SSO, audit logging, and admin scope controls.

Both are first-class. For industrial designers, Adam rebuilds pinched fillets as curvature-continuous blends, stages CMF directions, and batches photoreal renders that track the latest geometry. For mechanical engineers, it leans into BOMs, drawings, sourcing, and vendor email, detailing drawings with the tolerances and datum callouts you specify. Most teams run both roles on one product, and Adam is the connective layer between them.

Give Adam work that normally requires switching between CAD, spreadsheets, supplier emails, team threads, and engineering docs.

Good examples are cleaning a BOM, drafting an RFQ, preparing a design review, comparing suppliers, packaging a factory handoff, or turning a build thread into clear next steps.

You can start with a plain-language request. Adam reads the connected context, creates a workstream, and shows the result before anything important leaves your hands.

If a task needs clarification, Adam asks instead of guessing. If a task can be completed safely, Adam prepares the result and waits for review.

No. Adam is designed to work across the tools you already use. You do not need to move your team into a new project management system to get value.

The product works best when Gmail, Calendar, Drive, Slack, Notion, Sheets, and web research are connected, but you can begin with only a few tools.

Yes. Adam can prepare emails, calendar holds, document edits, summaries, and research notes, then pause for approval.

The point is to keep work moving without removing human judgment. You stay in control of what gets sent, changed, or shared.

Approval steps appear in the workstream with the relevant source context, proposed output, and next action. You can approve, edit, or ask Adam to revise.

For sensitive actions, Adam should return the work for review rather than executing silently.

Adam cites the sources it used whenever the work depends on research, past messages, documents, or calendar context.

That makes it easier to check the answer, spot missing context, and decide whether the result is ready.

Adam is designed around the places hardware work already lives: Onshape, Gmail, Calendar, Notion, Drive, Sheets, Slack, Messages, GitHub, Linear, and the web.

The exact set of live integrations can vary by workspace and rollout stage, but the product direction is cross-app hardware engineering work.

Adam can use multiple tools inside one workstream. For example, he can read a Slack thread, check a CAD note, draft a Gmail RFQ, and organize supporting files in Drive.

The user experience should feel like one delegated task, not a pile of app-specific automations.

Adam is built to preserve context across a task. It can reference the original request, connected files, message history, meeting notes, and previous outputs in the same workstream.

That context is what lets Adam return useful work instead of generic AI text.

The landing page shows the intended packaging structure. Pricing and limits should be treated as product copy until finalized by the team.

Individual plans are for people delegating their own work. Enterprise plans are for teams that need shared context, approvals, administration, and support.

Credits represent the work Adam performs across research, reasoning, tool use, and generated outputs.

Larger workstreams use more credits because they involve more connected context, more tool calls, or longer-running work.

Team is for small groups that want shared workstreams and pooled usage. Enterprise is for companies that need SSO, audit trails, governance, and rollout support.

The Enterprise tier should route to a sales or founder conversation rather than a self-serve checkout.

Adam should request only the permissions needed for the connected workflow. Workspace admins should be able to decide which tools are connected and who can use them.

For team deployments, access control and approval trails are part of the product surface, not hidden implementation details.

Adam is meant for delegated work where sensitive actions are prepared for review, not executed without visibility.

Enterprise customers should be able to discuss retention, governance, and security review during onboarding.

The product promise is that Adam helps with your workday, not that your team has to surrender control to an agent.

The right model is careful delegation: Adam drafts, checks, organizes, and prepares. You approve the work that matters.