DraftKings has been betting on agentic coding since 2024. It started with an agent that reviews every pull request, and now includes governed coding agents on every engineer's laptop, remote coding agents, and shared skills across the product development lifecycle. Each bet has taught us the same lesson: the model was never the bottleneck. What separated a useful agent from an annoying one was how much of our world it could see, and how little work a human had to do to show it. This talk covers what we built, what we should not have built, and how we took agentic coding from pilot to the organization in a regulated, public company. Key takeaways: → Don't build context management: Our chunking, diff-to-source mapping and custom review scoring were all made obsolete by someone else's release. Adopt an agent framework, and spend your engineering on wiring it into your own systems. → Your context surface is your advantage: Connecting agents to Jira, Confluence, code search, the data warehouse, observability, Figma and Slack turns a fast first-day engineer into one who knows why your codebase looks the way it does. → Distribution is the product: Treat agent tooling as a product with releases, an owner and a bug queue. Ship early into a public channel and let that feedback be your backlog. → Conservative defaults speed you up: Least privilege, a human in the loop on sensitive systems, and telemetry from day one meant one central security review instead of one per team.