Joining the Forward Deployed Team Family

When I relocated from Florida to the Bay Area to join Observe.AI at headquarters, I anticipated the biggest adjustment would be geographic. Different weather, different pace, a different environment entirely. What I didn't anticipate was how profoundly the move would reshape the way I think about building software – and specifically, how AI is delivered to the customers who depend on it. 

‍

That experience taught me something fundamental: the most effective AI is not built in isolation. It is built close to the customer, close to the product, and close to the cross-functional team that has to make it work in the real world. That is what Forward Deployed Teams make possible.

‍

Coming from a more traditional engineering background, I had always thought of software delivery as a linear process: design, build, test, ship, repeat. You solved the problem in front of you and moved on. Ownership ended at deployment.

‍

Building production AI agents is different.

Traditional Engineering vs. Production AI

Building production-ready agents is fundamentally different from traditional software engineering. In a traditional environment, you might build a feature, test it, and ship it. In the world of AI Agent Engineering, we are building "living" software that must navigate non-deterministic conversations in real-time.

As an AI Agent Engineer, that changes the way you approach problems entirely.

You are not just writing backend logic or integrating APIs. You are constantly thinking about:

• How an agent behaves during unpredictable conversations
  ‍
• How workflows adapt when customer data is incomplete or inconsistent
  ‍
• How system decisions affect real operational teams
  ‍
• How quickly feedback from users can turn into product improvements

One of the most exciting parts of this shift has been realizing that AI engineering is not purely a technical challenge. Building successful agents requires understanding human workflows, operational friction, communication patterns, and customer expectations just as much as it requires strong technical skills.

That balance between technical depth and real-world execution is what makes the work feel different from traditional software engineering.

Building Close to the Problem

Being physically close to cross-functional teams has made a huge difference in how quickly ideas move from discussion to implementation. Conversations that might have taken days across emails or meetings happen in minutes. Product feedback loops become tighter. Testing becomes more collaborative. Problems become shared problems rather than isolated engineering tickets.

What surprised me most after joining the team at HQ is how close the work stays to the real world. AI systems are not static products that operate the same way forever after deployment. They evolve constantly based on customer behavior, operational needs, and edge cases you could never fully predict beforehand.

The hardest problems aren’t purely technical – they live at the intersection of customer workflows, system behavior, and human expectations.

Before joining the team, I imagined engineering as mostly independent execution; developers building features while other departments handled delivery or customer communication. Instead, the Forward Deployed Team model creates an environment where engineers, designers, and engagement managers operate almost as a single unit.

That is what makes the Forward Deployed Team model so distinctive: it changes not just how software is built, but who is responsible for ensuring it succeeds in the hands of the customer.

The FDT Family: A Collaborative Blueprint

In the Forward Deployed Team (FDT) model, being close to cross-functional teams matters because AI doesn't live in a vacuum.

• The Engagement Manager (EM): Manages the client dependencies – ensuring we have the right API access and historical data to build accurately.
  ‍
• The Designer: Standardizes the "persona" and business rules, ensuring the agent feels like a natural extension of the client's brand.
  ‍
• The AI Agent Engineer: We turn those designs into systems that actually work in production.

The EM brings the customer context and the operational reality. The Designer brings conversational logic and user empathy. The AI Agent Engineer brings the architecture. When those three perspectives are in constant dialogue, the resulting system has a genuine chance of not just surviving, but thriving in a production environment.

Another thing that stands out about the FDT environment is the speed. Teams are iterating constantly. Instead of spending months building static systems, we are continuously refining prompts, workflows, evaluations, integrations, and agent behavior based on live usage.

It creates an environment where adaptability matters just as much as technical ability.

By embedding engineers, designers, and EMs together, working directly with customers, the FDT closes that feedback loop as tightly as possible. Insights from a live deployment don't have to travel through layers of abstraction before they reach the people who can act on them. They surface immediately to a team that's equipped to translate them into both immediate fixes and long-term platform improvements.

‍

For an AI Agent Engineer, who leads the AI Agent configuration at Observe.AI, that proximity is not incidental — it is the entire model. You are not guessing what matters to a customer. You know, because you were there when it didn't work.'s not just a better work environment. It's a fundamentally better way to build. You're not guessing what matters. You know, because you were there when it didn't work.

That's not something you can simulate from a distance. You have to be in it.

The Path Forward

For me, the move from Florida to the Bay Area was ultimately less about geography and more about proximity to a different way of thinking. Joining a Forward Deployed Team changes how you approach problems. You stop optimizing for isolated features and start thinking in terms of systems, outcomes, and the customers whose operations depend on what you build.

Being part of this team means being at the frontier of how enterprise AI gets delivered. We are not simply shipping code; we are establishing the deployment frameworks and operational standards that define how production AI systems are built, governed, and scaled across an entire organization.

The workflows, deployment models, and best practices that govern production AI are still being defined in real time. Forward Deployed Teams are not just contributing to that conversation — they are leading it.

The move from Florida to HQ changed more than my location — it changed my understanding of how software delivery actually works.

It changed how I think software should be delivered — collaboratively, hands-on, and always in close partnership with the customer.

If you are driven by building fast, staying close to real users, and pushing the limits of what production AI can do — this is where that work happens.

‍