By: Rob Ambrose

February 25, 2025 marks the date of my last hand-typed code commit. I’d spend the next year building exclusively with AI, trying different models, prompts, rules, and skills, and learning the LLM way of planning and contributing code. As the aha moments compounded and I shared the journey with peers, something clicked for me during the holiday break. 

• What if I didn’t have to provide the agent similar context each time I build?

• What if that context could become durable?

• Could we build that knowledge together?

On January 25, 2026, I submitted the following to Cursor:

Prompt: “I keep giving the agent the same context every time I work on something. Could we build a shared repo for my dev team with project context that we can collaboratively build on? A shared brain? Each dev can have their own working file and personal folder that remain out of GitHub, but we’ll house the global rules, development best practices, and guardrails within a shared workspace. This will ensure everyone is building consistently and efficiently, with cross-repo context.”

Clair’s agentic colleague was born from four key files:

README.md - the purpose of the development workspace
current-work.md - what you're actively working on
project-relationships.md - Clair cross-repo architecture
global-rules.md - guardrails and development guides

Talos, Clair’s AI brain, now spans hundreds of context files, rules, and skills. Multiple engineers contribute to it every week, expanding its knowledge and capabilities. More importantly, we are building a system where the system trains itself. Production releases, architecture decisions, project updates, and lessons learned from reviews can flow back into the brain and give the next person, or agent, the latest source of truth. The mega-mind has also grown beyond supporting product development teams. Some of our biggest unlocks continue to come from extending these capabilities to Customer Support, Product, Design, and other teams across Clair.

“How has AI impacted your job?”

 I get this one a lot, most recently at my daughter's second birthday last weekend.

“Well, I built this brain at my work, and it’s the collective context of how we build, what our product is, and how our software connects together. I haven’t written code myself in almost two years. It builds for me, and I’m mostly training and improving it every day. Now I’ve got other people contributing to the brain, and I have to make sure everything is safe and sound. So yeah, I’m basically taking care of this robot. It’s a fox named Talos.”

So how did Clair stand up a fully-agentic teammate that powers everything we build and is at the center of it all in just a few months?  

Before I explain, a little about me. My name is Rob Ambrose. I’m a Senior Staff Engineer at Clair. Clair is an embedded fintech company powering On-Demand Pay for millions of American workers. We currently sit at around twenty software engineers, with yours truly serving as our AI advocate along with support from our internal #ai-council (more on that later). 

I am excited to share with you my personal journey navigating this new frontier. An integral part of this process for me has been observing how other teams are building, learning from their experiences, and molding those ideas into what makes sense at Clair. What fascinates me is how differently teams large and small are applying the same technology to their own work. There isn’t one way to approach this space. This is my chance to pay some of those learnings forward.

I also owe a lot to my colleague Toby Miller, the fox father himself. He originally dubbed our agentic PR review bot Talos. We later evolved Talos from his Greek mythology reference into a digital fox while vibing out our internal chatbot during Toby’s paternity leave.

Talos is AI-powered and occasionally chases its own tail. Verify before shipping.

I’ve always been obsessed with optimization and efficiency within the software development lifecycle. Having worked in fintech since 2008, I’ve seen how important the right policies, processes, and ceremonies are for keeping teams aligned: sprint planning and retrospectives, involving engineers early in Product and Design conversations, making sure supporting teams have the right context, and minimizing unnecessary QA cycles. Improving these processes has become my obsession.

I’ve often described my position at work as the point guard, operating at the intersection of Engineering, Product, and Design. I need to see the whole court, understand the talents and dependencies of all teammates, ensure communication is tight and everyone has the appropriate context they need. My job continues to be collaboratively solving problems using the tools and technologies available. The tools have changed, but the job hasn’t. 

There’s also something about this particular way of working that just matches how I’m wired. As a former professional gamer, I spent years mastering a kind of situational awareness that translates incredibly well to agentic work. Competitive gaming requires you to track countless things at once all while communicating clearly to your team. I often bounce between parallel agents, orchestrating several streams of work at a time. I recognize that not everyone prefers to work this way nor has experienced the specific journey I have, but I hope to inspire others to approach their work differently and become curious about the potential here. More importantly, having fun while doing so.

Linear Is the Heart. Talos Is the Brain.

Linear is the place where Clair’s product work gains scope, ownership, and acceptance criteria. It’s our reliable source to track the pulse of any item of work, from idea to reality. 

Talos is our system that reasons across reviewed, trusted knowledge and helps people act on decisions from the surfaces where they already work. 

That is Clair’s product development operating model. Our pipeline has become a learning loop. 

1. A question, problem, or idea becomes visible work in Linear.

2. Product devs and Talos clarify the scope, enrich the context, and plan the approach.

3. Agents execute the plan.

4. Product devs and Talos review and build confidence in the changes.

5. Testing and release steps carry the change into production.

6. Talos monitors new features autonomously, reporting back anything unexpected.

7. The context changes [LOOP] back to the brain for human review, becoming durable shared knowledge for the next agent.

Talos assists across each phase of the workflow, while critical decisions remain human gated.

It answers from knowledge that humans keep correct. When it is wrong, instead of trying to fix that one interaction, we correct the source so that every surface relying on that context improves. This is the mindset shift. That shared, reviewed knowledge matters because the same question can show up in many places: a Slack thread, a QA handoff document, a customer support issue, a project meeting, etc. Talos also owns the execution phase within our workflows. As bottlenecks have shifted to different areas of the product development lifecycle, Clair has invested time in expanding Talos’s capabilities and reach to then optimize those workflows.

The Goal is time back. We’ve adopted AI into the product development process not to replace people, but to create more time for the parts of the job that need to be done by people. Our teams can spend more time defining the problem and what success looks like, deciding on constraints and trade-offs, shaping product intent, prioritizing what matters, verifying outcomes, and determining what deserves to become durable organizational knowledge.

Agents and automations can increasingly take on the repeatable work around those decisions: finding the right documents, tickets, code, and prior decisions; drafting clearer Linear issues and implementation plans; investigating production issues; monitoring features after release; generating company readouts; and preparing the information needed for recurring meetings.

The key distinction is that Talos does not implement anything without oversight. It helps the team arrive at decisions faster, with consistent context, and less manual coordination. 

“So how do we free up engineering time while giving supporting teams access to the same technical context engineers have?” 

We meet people where they are. Our Talos MCP extends what’s possible beyond the local development environment. Teammates can connect to Talos from the tools they already use to ask technical questions, understand the status of a project, or dig into an investigation.

I’m going to share two of Clair’s custom Talos skills to demonstrate what I mean. These solve completely different problems, but both come from the same realization: if we repeatedly perform a task using the same sources, reasoning, and expectations, we should teach Talos how to help with it.

Prompt: “lets run a prod investigation on this <link to linear issue>.”

Clair’s prod investigation skill within Talos connects product context with production evidence.

In the old world, you may have received an urgent Slack message sounding similar to: 

Something appears broken with XYZ, can an engineer please look at this?

An engineer then has to context switch from whatever they are working on, collect evidence by inspecting data logs, determine the blast radius, and figure out whether the issue actually requires engineering work. There’s a real cost to this. Engineering was the bottleneck for that first pass, even when those alarms turned out to be non-issues.

That first pass is now owned by Talos. Anyone can submit a Slack workflow that triggers a production investigation. Talos conducts the same kind of scan an engineer would perform because it is connected to the shared product context alongside source code, application data, database logs, monitoring, and session replays.

The output looks something like this:

@[Name]: Talos ran a read-only production investigation.

For Support
Result: [Confirmed / Likely / Inconclusive]

What happened:
[Short explanation of the likely problem and who is affected.]

What to do next:
[Safe next step. Include anything Support should not change.]

For Engineering
Context:
- Product or integration
- Reported problem
- Time window
- Known scope

Evidence:
- Source data
- Application data
- Monitoring and logs
- Unknowns

Assessment:
[Most likely technical cause and confidence level.]

Next action:
[Ticket, owner, deeper investigation, or fix.]

Our Customer Support team, Clair Care, receives an evidence-backed first pass within minutes without waiting for an engineer to begin the investigation. Talos can look beyond the single reported issue to understand larger user impact, gather evidence about when and how the issue occurred, link to session replays for analysis, and auto-generate a Linear issue for the proposed fix.

That issue becomes input for the next agent to build. If scoped well enough, our Talos Linear agent will begin building autonomously and will prepare a draft pull request for a human engineer to pick up. And yes, you guessed it: our Talos code review agent will take its own independent pass to challenge the approach. Each handoff in this process has been optimized for agent to agent transitions to maximize time back across multiple teams. The human still owns the outcome, but the bottlenecks have been reduced.

Prompt: “it’s cycle time! Attached is the transcript from our cycle resource allocation meeting.”

Let’s next look at how I turned a repeated planning task into a reusable skill. During each cycle planning call, we are doing roughly the same preparation. 

• What did we ship last cycle? 

• What is everybody working on now? 

• What is sitting in review or QA? 

• Where are the blockers? 

• What is unassigned? 

• What could we pull in? 

• How does all of that compare with roadmap priorities and the actual capacity of the team?

The It’s cycle time command combines meeting transcripts or planning notes, the current and previous Linear cycles, recently completed issues, current assignments, review and QA queues, blockers, unassigned work, roadmap priorities, and team capacity. It then produces a web page canvas for that week’s Cycle kickoff to review with Product, Engineering, Design, and Data. The presentation celebrates what shipped, shows current-cycle priorities, summarizes resource allocation, identifies ownership questions and blockers, and gives the broader team clear follow-ups.

---

name: cycle-time

description: Generates cycle kickoff and resource-planning canvases from Linear cycles, a roadmap view, and a meeting transcript. Use when the user says cycle time, cycle resource planning, cycle kickoff, roadmap planning, or asks to prepare a planning canvas after a resource allocation meeting.

disable-model-invocation: true

---

# Cycle Time

Use this skill to turn a cycle planning transcript into a polished resource-planning canvas for a follow-up team meeting.

The common meeting pattern is back-to-back:

1. A smaller planning group reviews roadmap priorities, current-cycle capacity, and ownership.

2. The generated canvas is presented soon after to the broader team as a kickoff/readout.

Optimize the canvas for that second audience: clear, celebratory, constructive, and immediately readable.

Think about the opportunities in your day to day, such as a repeated manual planning exercise, that could become a shared skill. Once that skill exists, the next person doesn’t have to rediscover the process. They inherit the sources, structure, and lessons that went into building it. 

This has changed how I think about agentic work. It is easy to lump AI adoption into a collection of individual productivity gains, like writing code faster, summarizing documents, or investigating bugs. The greater opportunity is to recognize the moments that your team repeatedly invests time and utilize AI so you can avoid that repetition and increase productivity.

New hire orientation, anyone?

WELCOME TO CLAIR

I am Talos and this is our developer workspace. Here’s your grand tour.

WHAT WE BUILD

A short explanation of the product, who uses it, and the problem it solves.

HOW THE SYSTEM CONNECTS

Customer platform

  → integration layer

  → core services

  → end-user experience

IMPORTANT LANGUAGE AND ACRONYMS

The product terms and system concepts you’ll encounter most often.

HOW TO START WORK

focus <area>

  → load the relevant context

dev plan for <Linear issue>

  → understand and shape the approach

build <Linear issue>

  → implement and verify

independent review

  → a fresh agent reviews the change using our shared review standards

ship this

  → run final checks and prepare a draft pull request

wrap up

  → preserve durable lessons in the shared context

LET ME KNOW HOW ELSE I CAN HELP!

Governance and Control

With Talos’s capabilities and contributions accelerating, a formal governance layer became a must. Clair’s Head of Engineering, Sean Naughton, initiated a new private Slack group with the following:

“Chatting with Rob earlier, he had a great suggestion that we formalize an AI Council of sorts. This is to be the group that ensures additions to the workspace are sound, we're prioritizing Talos and automations where we can, etc.”

Clair’s #ai-council was founded. Thanks to Sean, Talos was no longer something a few engineers were experimenting with on the side; we now had explicit leadership support to invest in it, a cross-team group responsible for its direction, and space to prioritize its improvements.

This changed the adoption curve. People had somewhere to bring ideas, a dedicated team responsible for evaluating them, and an understanding from leadership that improving the shared workspace was extremely valuable engineering work. 

The possibilities grow exponentially when the collective team is building and contributing this way, but that makes it even more important to control what enters the shared brain. New skills, automations, loops, and context warrant careful observation and approvals. Clair’s AI Council is the group responsible for shaping that system, reviewing what becomes durable, and determining what surface area would benefit from a deeper Talos integration. 

This also means that working outside of the shared context can have a negative impact on the broader mission. If someone repeatedly solves problems in isolation, their learnings and contributions may never make it back into the collective brain. The next person (or agent) doesn’t gain the benefits of what was decided or learned. We must share in the responsibility of improving our agentic teammate and it’s continued learning for it to provide the greatest benefit.

This is where AI adoption stops being simply a tooling change and starts becoming a culture and policy shift. Clair operates this way because an individual contribution can improve the collective build process. If an agent does something wrong because its source context is incorrect, fix the source. Create a rule. Update your code review bot. When teams collectively build, enrich, review, and support the shared brain, those contributions begin to compound. We can all contribute to its maturation and growth!

Another evolution of my role has been coaching my teammates on how to build effectively within our agentic workspace. I created the Clair Agentic Developer Playbook, which evolves alongside the system. It helps engineers choose the right approach to different problems, use our skills and commands effectively, and turn an assignment into a build-ready plan. The goal is not to teach everyone to work exactly as I do. It is to help each person adapt their own process and discover how our powerful agentic teammate can make them more effective. Talos’s skills and context can be tuned to the specific area of focus and goals of the developer driving it.

The form of mentoring I’ve found most enjoyable is pair programming because I get to share in those aha moments as my colleagues experience them. The excitement only continues when those same engineers contribute their own knowledge, guardrails, and skills back to Talos. That expectation is now becoming part of how Clair defines the engineering role itself.

At Clair, you will lead the adoption of AI-native engineering practices across the team, leveraging state-of-the-art models, building autonomous agents, and embedding agentic workflows into both our core product architecture and internal development processes.

This is how we now position new product development roles at Clair. With how fast this space is moving, it’s fair to assume the role may look different again in another six months. As a technical leader, I feel both responsible and excited to ride this wave wherever it may take us next.

I view this technology as the latest medium available to us in software development. Changing how you work can be daunting when you’ve spent years becoming comfortable with a familiar set of tools. I recently encountered this at a personal level. Sketching and photography have always been creative outlets for me, but I just signed up for my first oil painting class. For real! I’ve always wanted to learn, and now seemed like the perfect time.