Most companies think buying an AI tool is the hard part, but the real challenge is building the scaffolding that makes it useful. At Tilt, adoption only worked once engineers invested in documentation, rules, and workflows that embedded AI into daily practice. This post explores how that infrastructure was built, why it matters, and what other teams can learn from it.
Every day on Reddit, another engineer vents about leadership’s latest AI mandate. The frustration is understandable. At Tilt, we’re unapologetic about our AI adoption push, but here’s the thing: we learned early that buying the tool is just the beginning.
When I dig into these frustrated posts, the pattern is clear. Companies invest in the AI platform itself, then wonder why adoption stalls. What’s missing? The infrastructure that makes AI actually useful—training, documentation, and systematic integration into existing workflows.
This post breaks down how we built that infrastructure at Tilt. I’m going to call out specific developers who drove this work for two reasons: first, to show that successful AI adoption requires company-wide effort, not just a budget line item. Second, because our candidates read these posts, and I want them to see what their potential teammates are passionate about building.
Our Documentation Structure
Notion Documents (Core Concepts)
These are our human-readable philosophy docs—living documents where we hash out “the Tilt way.” Several engineers led this initiative to codify our engineering principles across areas like database design, telemetry standards, and third-party library evaluation criteria.
These documents stay in Notion because we want the comment history, the debate, the evolution of thinking. New hires can see not just what we decided, but why. While agents rarely reference these directly during coding, they’re accessible through our Notion MCP server when deeper context is needed. They were also used for the initial attempt at our Augment Rules.
Augment Rules (The Heavy Lifters)
This is where the Agentic magic happens. Augment rules translate our human concepts into AI-digestible guidance. They’re verbose, explicit, and frankly boring to read—which is exactly what makes them effective.
We organize these into three categories:
- Always Apply: Non-negotiables that apply to every interaction. Think Entity Framework patterns, code structure standards, security requirements.
- Automatically Apply: Context-sensitive rules the agent can invoke when needed. Our webhook handling rules are a perfect example—Stripe, Plaid, and Persona each have their own authentication quirks and JSON conventions, so we need rules that activate only in specific scenarios.
- Manual Apply: Specialized instructions invoked on command. This includes data warehouse procedures, planning frameworks, and experimental rules we’re testing before broader rollout.
User Guidelines (Personal Preferences)
Individual developer customizations live here, often things that could not live in rules. I frequently create Linear tickets through Augment, so I store my project IDs, my UserId, etc and assignment preferences. It’s speeds the agent up by not having to look it up.
Augment Memories (The Learning Layer)
These auto-generate based on interactions but remain human-editable. For larger teams, we avoid over-relying on memories, instead using them as feedback loops—they show us where our rules need refinement and when agents need additional context.
The Real Investment
Here’s what we learned: AI adoption isn’t about the tool—it’s about the discipline to document, systematize, and continuously refine how your team works. The companies succeeding with AI aren’t just buying platforms; they’re investing in the scaffolding that makes those platforms actually useful.
That scaffolding doesn’t build itself. It takes engineers who care about craft, leadership willing to invest in process, and a recognition that this is infrastructure work—unsexy but essential.
The frustrated Reddit posts will continue, but they don’t have to include your engineering team.
About James Garrett

👋 I’m James, a seasoned backend developer with interest in crafting solutions on the C#/dotnet stack, scalability and performance challenges are my favorite. My career in software development has been a combination of startups and Fortune 500’s with startup like cultures. Mid week you’ll find me coding away, but weekends are time for fishing, hiking, boating— anything outdoors!
In my toolbox, JetBrains Rider, macOS, The Azure Cloud platform and of course the best coding language (C#) are my preferred environment. Their intuitive interfaces and powerful features enhance my developer experience.
_While I love software development, I don’t find it particularly fun in a vacuum. The projects I’ve most enjoyed in my career are those where I get interact with a team to solve new challenges— that’s why I love it here at Empower. _
What keeps me excited to come to work everyday is the fact we have a strong team based culture. Almost daily I’ll hop on a call with fellow Engineers or Product Managers to pair up on something. Culture isn’t an accident here, it’s an investment. Twice a year we bring the team together in person to get to know one another, learn what different pods are up to and form relationships.
Keep reading
-
-
AITeaching AI to Read the Room: How We Built an Automated Incident Classifier
After 18 months and ~800 incidents, our Rootly classification fields were mostly empty, no one fills in six drop-downs at 2am.
· 10 minutes read -
AIAI DevOps: Building Intelligent Incident Response Systems
On-call shouldn’t start with archaeology at 2am.
· 6 minutes read
More in AI