Sales-Led AI-Driven CRM with Cursor × Attio

"Fill in the CRM and a quote is automatically generated; once the contract is signed, the customer is automatically handed off to CS." This kind of end-to-end automation is the dream — but achieving it within a CRM's own ecosystem means living with the constraints of whatever integrations it supports, while building custom connections on your own requires engineering bandwidth and significant effort.

In this article, we share a hands-on case study where a sales rep — not an engineer — built a fully connected CRM environment spanning lead capture to billing, using Cursor (AI coding agent) × Attio (AI-native CRM). It's an early-stage, real-world record that we're still actively refining.

The "Classic CRM" Problem

Why sales infrastructure falls apart

Does any of this sound familiar?

• Too complex to use: The more powerful the CRM, the more overwhelming the settings — teams end up using the defaults and nothing more
• Impossible to maintain: The person who knew how to configure it has moved on, and no one dares touch the settings
• Data nobody acts on: "We enter data, but it never informs decisions"

We faced the same challenges. Our CRM had been deployed, but the person who held all the configuration knowledge had left, effectively making the system unmaintainable. As the business scaled, the number of things we needed to track grew — but we couldn't keep the CRM flexible enough to keep up. The gap between how we actually worked and how the CRM was structured kept widening.

The deeper problem: fragmentation

The second issue is process fragmentation.

Leads in the CRM. Meeting notes in Google Docs. Quotes in a billing tool. Contracts via an e-signature tool. Tasks in a project management tool. Each tool is excellent on its own — but when data moves between them by hand, you get transcription errors, missed information, and status mismatches.

"Fill in the CRM and a quote gets generated automatically; once a contract is signed, the customer is automatically handed off to CS."

That level of end-to-end automation is what we were after — but CRM ecosystems constrain which integrations you can use, and custom-built connections require engineering resources and real effort.

Why Attio

API-first × flexible data model

As we reassessed our CRM setup, we evaluated several options. The three things that mattered most to us:

1. Flexible data model: Not a rigid object structure, but one we could shape to match how we actually work
2. API-first design: Built for extensibility and external integrations from the ground up
3. Realistic cost to operate: Something a small team could adopt and run without strain

Attio is an AI-native CRM that has been gaining traction in recent years. You can define custom objects freely, and its Workflow feature lets you send HTTP requests to external systems. Rather than "locking everything inside the CRM," its design philosophy is to use the CRM as an integration hub, connecting each process to the best-fit tool.

Natural fit with GitHub as a workspace

At ROUTE06, we use GitHub not just for development — we've adopted it as our company-wide workspace. Project management, documentation, decision records — everything lives on GitHub.

Attio's API-first design fits naturally with this GitHub-centric way of working. When an event fires in Attio, GitHub Actions runs. When an Issue is closed in GitHub, it's reflected in Attio. This bidirectional sync works without any dedicated middleware — and that was a key deciding factor.

Why we chose GitHub Actions + Attio Workflow over iPaaS

When people think about integrating tools, Zapier or Make (iPaaS — Integration Platform as a Service) are natural choices. No-code automation is appealing. But we made the deliberate decision to base everything on GitHub Actions and Attio Workflow instead.

The reason is simple: we didn't want to add more tools.

Introducing an iPaaS layer doesn't just add another tool — it also splits your logic across multiple places. "Where is this automation running?" becomes a question that spans Attio, GitHub, and the iPaaS — and that fragmentation becomes a new source of tribal knowledge.

With GitHub Actions, workflow definitions and scripts all live in the repository as code. Changes are tracked in Git, reviewable, and auditable. Attio Workflow handles trigger configuration; actual processing logic stays in GitHub Actions. This division of responsibility means everything that happens is visible and understandable from one place.

And because the code lives in a repository, you can open it in Cursor and ask what it does. Even if you can't read source code, you can ask "What does this workflow do?" and Cursor will explain it. Automation doesn't become a black box — something that's hard to achieve with an iPaaS GUI.

Built by Sales, Not Engineering

"Automate your own work, yourself"

The person who built this CRM environment was not an engineer. It was a sales rep.

The tool: Cursor — an AI coding agent. As mentioned in another article, an AI-driven development environment lets non-engineers build systems on their own laptops. We applied that same approach to building our own sales infrastructure.

A typical Cursor session looks like this:

1. Describe what you want in natural language: "When a Contract is created in Attio, I want a quote to be automatically generated in Board"
2. Code gets generated: Python scripts, GitHub Actions workflows, and API integration code are proposed
3. Test it: Run it and verify it works as expected
4. Request adjustments: Say "there's an error" or "I also want to sync this field" and it gets fixed

We repeated this cycle, expanding the scope of automation step by step.

What we built — current state

Here's the scale of what we have running at this point. We're still in early operation, with improvements continuing week by week.

The operations manual also emerged from Cursor conversations. As we worked through "what's automated versus what's manual," it naturally took shape as documentation.

Why it makes sense for sales to build this

You might wonder: "Shouldn't engineers handle this?" But the most critical ingredient in CRM design is understanding the business process.

• How do leads actually come in?
• What does the sales team need at each stage of a deal?
• How should contract details map to quote line items?
• What information needs to be communicated during CS handoff?

The people who know this best are sales reps themselves. The traditional approach — sales describes requirements, engineers implement — introduces a gap between intent and output. An AI-driven development environment lets you close that gap to near zero. If you can articulate your workflow, it can become a working system. That's been our experience.

End-to-End: From Lead to Invoice

Here's an overview of the CRM as it currently stands. The key point is that six phases connect seamlessly — with manual steps kept to a minimum and everything else automated. We're actively using this in production, making small adjustments as we go.

Full integration diagram

Six external services connect around Attio in an event-driven architecture. Data doesn't flow one way — it syncs bidirectionally between GitHub and Attio.

Phase 1: Lead Capture — In Attio the morning after you exchange cards

Exchange business cards at an event. Come into the office the next morning, and new records are already in the Attio lead list.

Every morning at 7am, the Sansan API pulls business card data from the past 7 days and creates People / Companies records in Attio — name, email, phone, title, department, company info. Duplicate checks against existing records are automatic.

The card "owner" information is also synced, so you can see in Attio whose card it was — automatically.

Phase 2: Deal Management — No more "copying to CRM"

Open the target People record in the lead list and click Run workflow. That single action triggers:

• A Deal is automatically created and the lead status changes to "In Discussion"
• A parent Epic Issue is auto-created in GitHub
• A Sub-issue for the first meeting is also created
• The deal is automatically added to GitHub Projects

After each meeting, write the notes in that Sub-issue. Close the Issue when done — GitHub Actions fires, and the Issue content is automatically synced to Attio as a Note on the Deal.

"Copy to CRM" disappears as a task. You write meeting notes in GitHub; they show up in CRM automatically. For teams that use GitHub as their workspace, this feels entirely natural.

Phase 3: Contracts & Documents — 4 automated actions from 1

When the deal progresses and a rough value is visible, create a Contract. Select service, contract type, environment, and plan — and save. That single action triggers four things automatically:

1. Auto-generate Line Items: Search the Products master for matching items and register contract line items automatically
2. Auto-generate Board documents: Register the customer and deal in Board; quotes, purchase orders, and invoices are auto-generated
3. Auto-create GitHub Issue: A contract management Issue linked to the parent Epic is created
4. Auto-advance pipeline stage: The deal stage changes to "Proposal" automatically

If contract details change later, run the workflow again and Line Items and Board documents are regenerated. If there's a data mismatch before and after the change, an alert is automatically posted to the Contract's Comments.

Phase 4: E-Signature — From signed contract to stored PDF, automatically

Review the quote in Board, then send a signing request through DocuSign. Once the counterparty signs, the following happen automatically:

• The signed PDF is auto-uploaded to Google Drive
• The contract URL is auto-recorded in the Attio Contract
• A signature-complete Note is automatically added

The only manual step for sales is sending the DocuSign request. File management and CRM updates afterward are fully automatic.

Phase 5: Deal Won → CS Handoff — No manual communication needed

Confirm the signature and change the Contract status to "Active." That's the deal-won trigger.

From that one action, the following cascade automatically:

• Board status changes to "Won"
• The contract management Issue in GitHub gets the contract URL as a comment and closes automatically
• The Deal pipeline advances to "Won"
• A CS management record is auto-created with "Handoff from Sales" status
• An account provisioning Issue is auto-created
• An onboarding Issue is auto-created

There's no manual handoff communication from sales to CS. CS reps open the GitHub Project board and see their assigned Issues lined up. What to do, which customer, contract details — everything is in the Issue.

Phase 6: Billing — Invoice ready when the contract is created

When a Contract is created in Phase 3, invoice data is already auto-generated in Board. Monthly/annual billing cycle settings are automatically pulled from the Contract attributes.

When contract terms change, run the workflow in Attio — and Line Items and Board documents (quote, PO, invoice) are regenerated against the latest contract details.

What the AI-Driven Build Process Actually Looked Like

What we did in conversation with Cursor

This CRM environment wasn't built all at once. It evolved through ongoing Cursor conversations, phase by phase.

Phase 1 — Schema design:

We started by designing Attio's object structure: Companies, People, Deals, Contracts, Line Items, Products — what attributes each object needs, how to relate them. We consulted Cursor on "what fields matter for deal management," incorporating frameworks like BANT and SPIN into the schema.

Phase 2 — Integration scripts:

Next, we built integration scripts for each tool: Sansan → Attio card sync, Attio → Board document generation, DocuSign → Google Drive → Attio signing flow. We had Cursor research each API spec, then iteratively generated, tested, and refined the Python scripts.

Phase 3 — Workflow automation:

Once the scripts were working, we built event-driven automation using GitHub Actions. Attio Workflow fires repository_dispatch to trigger GitHub Actions, which runs the scripts. This architecture also came together through Cursor conversations.

Phase 4 — Manual generation and migration:

After validating in a test repository, we migrated to production. We ran the go-live verification with Cursor, and the 1,200-line operations manual was generated through those same conversations. "What happens automatically in Step 1?" "What to do if there's an error?" — articulating what we'd built deepened our own understanding as we went.

CRM isn't something you "deploy" — it's something you grow

What this work has made clear is that CRM isn't something you deploy — it's something you grow.

As the business evolves, what needs to be tracked and how work flows changes too. Add a new service and the contract template changes. Improve the CS onboarding process and the Issue template needs updating. Whether a CRM can keep up with those changes is exactly what determines whether it stays useful or becomes shelfware.

With an AI-driven development environment, the cost of change drops dramatically. "I want to add this field." "I want to automate this condition." You tell Cursor and it gets implemented. We're still early in our operations, and we're making small improvements every week. The cycle of continuously evolving the CRM is now in the hands of sales — and that's the biggest value we've found.

Closing Thoughts

CRM falls apart not because of the tool — but because the CRM can no longer keep up with how the business changes. When how you work shifts and the CRM can't follow, no matter how powerful the product is, it eventually gets abandoned.

AI-driven development offers one answer to this structural problem. Sales reps articulate their process, tell Cursor, and the CRM's structure and workflows get updated. When the cost of change comes down, CRM stops being a "deploy it and you're done" tool and becomes a foundation that grows with the business.

There's more to come. Attio has published an MCP (Model Context Protocol), and we can already see a world where AI agents read from and write to CRM data directly. Without going through GitHub Actions, an AI agent could search and update Attio records, summarize deal status, and post to Slack — all naturally through MCP.

We're also looking beyond sales and CS. Partner management is next on the roadmap — using the same Attio × GitHub foundation for managing reseller and referral relationships.

At ROUTE06, we're actively applying AI to the construction and operation of our sales infrastructure as we work toward an AI-driven sales organization. The Cursor × Attio CRM build is one piece of that practice. We're still mid-journey, and we plan to keep sharing what we learn along the way.

If you're interested in transforming your sales operations with AI, or want to explore this together, we'd love to hear from you.

Contact us