Our first job was forward deployed engineering — or maybe beyond that

Lately, maybe for the last one year, we've been seeing a lot of hype — and a rise in jobs — around forward deployment engineering. Almost all the frontier AI companies, big tech firms, and platform companies are increasing their hiring for forward deployed engineers. Essentially, the role is adapted from Palantir's famous forward deployed engineers — to address the deployment gap: adapting Palantir's platforms (first Gotham, then Foundry) to the real world problem solving at different customer companies, adapting the data, the workflows, and building the solutions and methods on top of that.

It was pretty much there previously, prior to the AI era itself. Right now we have all the language models — but if you consider 2020, before the influx of large language models, Palantir's Foundry platform already had the capability for data engineering, data integration, and scaling various methods: data analysis, operations research, optimization, visualization. Along with that, people could build workflows or quick applications and collaborate on it.

Why I'm telling this — when I was working at my first job, there was a partnership to solve a specific petrochemical company's sales and operations planning problem, which involved data engineering to planning and a close loop around that. There was a studying of what platform we can use — Palantir Foundry, Kinaxis, o9 Solutions were the options. At that time, I had even given my interview to a Palantir Foundry program — maybe it's called implementation partners. But that's not exactly the forward deployed engineers, because they come from the Palantir side. But yeah — I'll come up with why our first job is more than forward deployed engineering, right?

Apparently, the training was on PySpark and SQL. What we were expected to do: once the ontology is built — or even while building it — there were a lot of use cases. It was kind of similar to dbt's lineage, but not exactly: Palantir's ontology connects data, workflows, people, and various things, whereas dbt is more for data transformations. Once you connect things as nodes, you can write functions — machine learning models, or feature engineering — so it's very easy to get the data and manage it at the nodes; a semantic model or an ADS coming from different sources, all in one place.

There were also similar approaches with a DAG — a directed acyclic graph — which isn't ontology, but shares the same graphical way of organizing the work, the assets, the solutions. My friends were working on Airflow, automating audience selection and campaign rollout — its own data processing, building models, running for hours on XGBoost or gradient boosting, then the score, the heuristics on top, get the audience, push it to reverse ETL. Everything organized in one similar structure — because it's all about how you organize, how you manage, how you scale.

The platforms — either Foundry or something — it's not like "oh okay, we have our unique model in place." Not like that. Now, with Foundry, or even the AI platform, AIP, one can own the sovereign AI stack and everything. Things have evolved. But ideally, this was the scenario.

Now you'll see what the different companies really want in terms of forward deployed engineering. Let me connect this to how our work was there: the intersection of customer problems — or business, math, technology, and science, as we used to say. It was also intertwined with cultural, practical thought processes and practice, right? It's not always just technical excellence — there were a lot of other supporting elements, and we were trained, led to practice all these things, to advocate for them, from day one of the company. Or maybe that was instantiated during the on-campus, on-site interview itself — because those two days at Mu Sigma were slightly immersing us into their world of problem solving.

Now, let's say you take a company into routing AI for their resource planning, CRM, and various analytics workflows — then there exist tens and fifties of companies at different levels: from partners and vendor solutions to direct product companies, a mix of things, right? So that's why I could put forth my ideas, the learnings, and how it was all inculcated and compounded over the time — because forward deployed engineering is not just letting people work on problems; it's a different thought process, practice, and point of view.

So — welcome to: our first job was forward deployed engineering, or maybe beyond that. And a sneak peek into the art of problem solving, and how it is very much relevant and important in real world problem solving with the help of AI and data science.

My first job as a trainee decision scientist at Mu Sigma

If you haven't heard about Mu Sigma — it's one of the largest pure-play decision sciences companies, known for its way of solving problems with a mix of business, science, technology, and design thinking. If you think it through, it's beyond a management company, beyond an IT services company, beyond a product company. And I always feel cherished — it's not a fake gratification, but true gratitude, and a reflection, that I started my career there. I've talked about it before; here I just wanted to share how we solved problems, what the exposure was, and why it is beyond forward deployment.

Let's start with the definition of forward deployed engineering, and then how our work was, and how it is far from that. Going through a couple of blogs written about forward deployed engineers, they highlight it at the intersection of three things: building and running applications, data flows, and infrastructure; partnering with customers — translating their problems into clear requirements; and owning the outcome — deploy, evaluate, troubleshoot, improve.

I really like this — it sounds so straightforward. But when you think from the problems, it's not like that. The flow is more like: understand the problem, build the production AI application, integrate the APIs, pipelines, systems, deploy it, get feedback, improvise. So it's similar to any product problem-solving life cycle. This is not very specific to a forward deployed engineer.

Think of a well-defined software engineer or product engineer at a startup or a tech company — the typical work would be like that. Even someone in a product engineering team, working across the company — one software engineer works with the CRM team, another with GTM, another with other things. In these situations, where an engineer works on the different problems of the company itself, it's highly defined. And the friction to solve the problem is very limited, because all the systems are already in place. You can fail things or break things. Such leverage, such sophistication, one may not get in a forward deployment role.

So that's why it needs a crucial understanding of various things — a broader view of how problems evolve and behave, the dynamics of the problem. To put it simple: in a product company, a tech or SaaS company, the GTM strategy is highly playbook-oriented — no extraordinary critical thinking, the problem is not completely different. And the work is well defined, confined by the Jiras.

For example, people at AWS, or Google, might own a feature release, a system upgrade, or a new product point of view — and it's very compounding: a product can take years to evolve, solved step by step. But on the other side, the customer problems are either well established and not yet solved, or partially solved with leakages, or with downstream impacts — wasting too much money, not efficient in decision making, or not having anything at all. These are more real-world problems. It's not just system- or software-oriented; it can involve business decisions, operations in the factories or on the ground, fund allocation, many aspects. It's all very interconnected. So the appreciation of the interconnection of problems is really important.

Just think — tomorrow, you, the reader, might want to work as a forward deployed engineer. I'd suggest: don't limit your thought to "oh okay, that's building some agents for one function," or "building a chatbot," or "building a RAG system." It's beyond that. Building a RAG is just a methodology to solve the bigger problem.

One good, relatable example: there was a problem I was working on, with bigger enterprises — especially manufacturing or process engineering industries. They have suppliers, vendors, engineers — a lot of upstream players. They provide materials, handle logistics, handle a specific process. And they want to get the SOPs, proposals, and all the required documents; for each and every work, they want validation against the compliance, the skills, the ability. And it's not just validating in the first step, but maintaining it — how it goes ahead once the work is given to one specific vendor. So it starts from getting the proposals, to ensuring things are going fine, to managing the ongoing work.

It involves document collection, or extraction of compliances, their policies and details. If you take a supplier for a process company, there's a lot — configurations, certifications on the control valves, or some components. Think of any process engineering component: control valves, switches, filters, heat exchangers. And each component has matching of the compliance, the configurations, how many days, how much billing. It also involves fitting in and operationalizing — who the engineers are, the partner engineers, their ability. So it has matching, planning, filtering, and continuous tracking.

Ultimately, it's not one dimension — not just a document extraction problem, or a data matching problem. It's understanding the business process, the engineering components, dealing with loads of raw documents and data, and scaling assistance. A bigger company — a trillion-dollar process engineering company, or multiple processes across multiple nations — wants to do the digital transformation and keep it: a one-year, or one-and-a-half-year, engagement where you keep improvising. It's not one engineer's thing — it's a group of engineers who own the entire thing, from data engineering to deployment, scaling, mapping out the process, understanding different portfolios. And it also involves change management. Previously people were doing things with tribal knowledge — scattered in Excel sheets. So this kind of scale is what one would expect.

Take OpenAI's Frontier platform pitch, or take Palantir — they'd have a similar one. If you understand the case studies of Palantir, or even Distyl AI, you can see the scale of the problems. It's not just how typical ML engineers start — "okay, give me a dataset, I'll keep tweaking the model," or "just deploy it as one API call." It's a very holistic thing that involves process, data, workflows, context, systems. So this is how the real problems are, and that requires specific engineers.

These companies come up with baseline approaches, with a platform in place — so that putting a wrapper around everything, connecting all the documents and process flow, reduces the friction. Because when you approach this without a platform — building everything as systems and connecting it all — the problem gets much worse. We had a requirement to build everything on-prem, on the Microsoft ecosystem, with constraints like you can't use this package or that one; that's extra dead weight from the harsh requirements. And customers often have a fragmented adoption — SAP, Cloudera, some low-code analytics platform — and you have to connect it all and make it workable. One thing, though: we were not trained on any specific platform; we were trained to approach from first principles. Learning the nuances of a platform is not a big deal — as a group effort, you figure it out.

Now consider the contemporary forward deployed engineer roles. Almost all these companies solve these issues with platforms, connections, easy-to-deploy systems — on-prem or cloud — with inbuilt connectors, automations, scaling elements. So it reduces a lot of the friction, and lets you focus on the core product. Over the years, if I compare what we were working on versus contemporary forward deployment engineering — the contemporary one is easier to get started with, solving the real problem rather than figuring out the platform and system side of things. And it reduces the need for human resources as well.

So it's not the straightforward thing — "partner with customers, build and run, own the outcome." It has a lot of nuances. And I'm talking about bigger companies — Fortune 500, Fortune 50 — who can invest five, ten millions just to get these people to solve their real problems. That needs a lot of effort — not just access to the methodological corpus, "oh, it's easy to put this model in place, easy to use this platform." The whole problem is bigger than the sum of its parts. From the holistic perspective it's always complex: problems are not stable quarter over quarter, the nature varies; and when you solve parts of the problem, even how it responds might change — as well as these problems being interconnected with one another.

I actually learned this from one very good school of scientific thought — complexity science — to understand how the world works, from simple fractals and colonies to bigger organizations. If you're interested, read the book Scale, by Geoffrey West. You can appreciate the similarities of problems at different scales — be it a small viral infection, or a very big supply chain catastrophe of a Middle Eastern oil company.

The roadmap you see on YouTube isn't enough

If you go through the recent YouTube videos on forward deployed engineering, they come up with a roadmap of sorts — but at a very shallow level. They list it down: software engineering skills, Python, SQL, applied AI — prompt engineering, RAG, LangChain, vector databases — cloud deployment on AWS, and some customer-facing work, which people think, "oh okay, it's much easier to handle customers." And I truly believe this is not at all enough. Let me explain why. There are two aspects.

One is from my experience as a client, in a way. Before joining, I was helping a friend's startup, setting up their AI engineering practice, working on various problem statements, especially on visual language models. Before I joined, they had committed to an engagement — around ₹30 to 40 lakhs — to buy a document extraction platform from a very renowned company. The startup got the support of one customer success manager, or one person from their SME team, and on-site engineers from their implementation partner companies. But these people were trained on what's in-house — how to install the platform, connect the data, feed the input, get the output, add some Python-based custom workflows. They were not really able to understand the quality of outputs the customer wants.

Consider a list of medical documents, and the customer wanted very structured information out of it, to do analysis and fact-checking: verifications on symptoms, malpractices, side effects. It's not just OCR — if it's just OCR, you feed things in and get them out, but that's one part. The other work is structuring it, so you can feed many downstream applications that face different problems: medical malpractice, checking for side effects, validating it. The company wanted to solve many downstream problems with the help of medical and insurance documents.

So just to get started, they adapted that platform. Then there were a lot of frictions — the vendors couldn't really understand things, and they overpromised: "we'll be able to do RL, we'll tune the models" — but ultimately that support demanded another platform purchase, another subscription, another VPCs. And the implementation partner engineers — who might call themselves forward deployed engineers — couldn't really understand the requirements, or think beyond the linear way of getting the platform to run. Because the real problem is not just getting the platform to run — that's simple — it's beyond that. So they decided to build in-house from scratch. And then we progressed — that's a different story, because I left in between for my masters. But this is how you can see the in-depthness of solving a customer's problems. It's not a linear thing; it has a lot of nonlinearities — sudden saturations, then a sudden peak in the learning curve.

So there are two aspects. Number one: a company that wants to set up a forward deployment team might feel it's just a matter of time to hire people. Or the other way around — people looking at forward deployment engineering might think, "okay, I just follow some roadmap, and somehow clear the interview." But in reality, it demands a lot. So it's good to develop the art of problem solving — because a problem contains different elements, from people, methods, process, platforms, even research, depending on the nuances of the customer problem. It's not just a typical machine learning way of "let's do some feature engineering, some hyperparameter tuning, adapt some SDK." It might need original thought — need not be benchmark-cracking, but something specific, peculiar to the problem.

So that's why I'm trying to define the perception of forward deployment engineering. The shallow perception says "I follow ten steps in the roadmap," or "I go through a set of YouTube tutorials and a couple of projects." But it involves a mix of design thinking, systems thinking, foundations across AI, data science, data engineering, an essential amount of software engineering — programming, deploying systems, thinking about how you'd scale or use resources optimally — and it's a continual learning process.

How we were actually trained — the art of problem solving

That's why, in my first job, we were trained from day one, at various levels. Not just hiring people who can code on Python notebooks, or who excelled at DSA. We were hired with the mindset — the hunger to solve problems, to learn, to continually evolve, and the curiosity to continue. Because the belief system, the school of thought we operated on, was three things: learning over knowing, extreme experimentation, and an interdisciplinary perspective — continuing to interact with the problems. Because this way only, you get better ability and excellence.

Let me share how we immersed in that journey. Today, companies have account executives and presales doing the sales calls, handing over one to one. But in my first job, we were given the opportunity to scale our abilities. You might start on building datasets or improving models — but you're not saturated with "okay, all these years I'll just build and tweak models." No. You scale the learning-and-doing experience vertically as well as horizontally. Vertical is going deep into a problem space — customer analytics, loyalty problems, data engineering, or a real-world evidence problem for pharma. Horizontal, at the same time, is business development — presales, prototypes, pilots.

To get a new logo, a new deal — an account or a vertical has its own dedicated group, everyone at the same level; it's not a separate section you hire. So an engineer — call it an applied scientist — does the delivery work, the actual client work; but along with that, to expand the account, he'd also do the business development: with other organizations in the same client company, or targeting similar companies in the same vertical. So the sales process is a mix — actively preparing for the problems you'd expect from those target clients, curating case studies, working on prototypes, doing sales navigation, and presenting the details. It's not fake promises; it's showing what's possible, showing relevant things — all supported through internal platforms to improve the quality of the solutions and the thought process.

So there are two aspects. One is people who gain from collective experience, versus people who learn and figure out things by first principles. We were in the second category — learning to solve problems from first principles, rather than just memorizing and relying on past experience. That's the learning over knowing. Every time you go to a new customer, you prepare a lot; you learn from what others have solved, so you can come through new problems.

It also involves systems thinking, design thinking — and a wonderful thing: empathy. Because at the end of the day, you deal with a human — someone who owns dollars, facing the pain of the problem: inventory management, supply chain, revenue growth, saving money, marketing strategy. Understanding their problem, and what they give importance to, is really important — because ultimately you want to win that proposal, and they're hearing it from other vendors too; it's a competition from there itself. A few might give you a pilot, where you solve a small chunk, and they see "okay, they have the potential, the skills" — and then you expand the team, get people from the training pool, and give them the space and guidance to learn and adapt.

Living in the customer's problem

From my second year onwards, I was helping other engagements, and working on my own — as an individual, and with two other people. Sometimes it's a shared engagement, where one works on two different threads; and you continue to help other teams. Every day, day in and day out, from nine or ten in the morning to five, six, seven in the evening — every interaction: whether you're building a neural network or a computer vision model, or talking to someone into simulations or optimization. So you keep interacting on different problems, different bottlenecks — at the people level, the systems level, the methodological level. We never resorted to one method — we always validated it, kept a champion and a challenger, tested it, scaled it. And it's not just showing it works on deployment and flying off — it's all continuous support; some of my friends worked a parallel thread of just weekly eight, ten hours of support, on bugs or improvisation.

Along with that, you get to present at CXOs, steering committees, weekly and monthly business reviews with customers — and across business unit heads: what's the billing, how we're improving it, expanding it, what the ongoing problem is, whether there are any red flags. And as we solve real problems, sometimes problems evolve, or we get more clarity as we move forward — because not all these problems started with fully defined documents. As we go in-depth, we figure out the blind spots, the approval issues, the implementation issues. Sometimes it gets solved through cross-team collaboration — I helped a lot of teams across business units, building proposals, pilots, prototypes, fixing ongoing issues, figuring out better methods.

For example, I made many friends that way. One close friend was working on a price-sensing problem — extracting important events from news articles, then fusing them with price forecasting, to see how short-term fluctuations, based on political, geopolitical, operational, or business events, can sense the price in the global market. That's how I made a bunch of friends across the organization, and got to present to CXOs. Even six months in, I was presenting twenty-plus hypothesis-testing results to the CXO of a CPG company, working directly with VPs of analytics — presenting our work, even debating and betting against the conventional approaches. So there were no hierarchies; it was always trusting the talent, nurturing them. For every one of us, it was a university, a roller-coaster ride, where we worked on real problems and made real impact. As a team, we won a multimillion-dollar engagement against companies bigger than us — set up the team, sourced the people, worked on the methodologies. Obviously there were frictions — a misunderstanding in the problem statement, a lack of clarity early on — but it's all figure-out-able; we acknowledged it, progressed, and built. And thousands of people had the same experience.

Right now, my friends doing internships across the Bay Area often tell me, "it's so boring, I'm just testing one bug, or implementing a small pipeline." But my internship, back in 2019 — we got to work on a real problem, by shadowing people, immersing ourselves in the same way of approaching the customer's problem: the customer's empathy, detecting their problem DNA, defining the solution, building it, presenting it, storyboarding, getting the feedback, improvising. So it's a very holistic problem solving. That's why we learned the art of problem solving. It's been seven years, and I can get into any industry and give a better approach than what people refer to from ongoing blogs, YouTube tutorials, or random conferences. Because I've tested it firsthand — these learnings really help, not just at the excellence in machine learning and data science, but the holistic things: the systems side, complexity, approaching problems with better clarity, handling people, handling tough times.

And we never worried about it — we always had love for that. Sometimes I feel bored if I don't see such complexities, such hardships, in the journey. There was a phase — three, four months — where I was just prompting LLMs to extract signals from the logs. But then I approached my manager and said, "I'm not meant for this. I can help you solve any problems, I can take up some of the other problems." So that's how I ended up working on multiple threads, and helping other people.

The true intersection — and why I call it decision engineering

Since my early experience, the company meant the true intersection of math, business, technology, and science. We had the traces of someone who could do better product or project management; someone who could do systems thinking, or structure the solutions; and have a scientific take on different problems — and still scale, still do the engineering. So it's a mix of research, business, product. A lot of people never had such exposure, or never acknowledged what we were working on. And when I see what people talk about, or pretend, these days, I feel they're just scratching the surface — doing it for marketing, not the real problem solving. People keep coining words — ship fast, fail fast, break things, agency, token matching — but they just scratch the surface, joining waitlists. Living inside the customer's problem, as Palantir says, is not linear; it's a multidimensional effort to learn and do.

But I still believe learning over knowing is very important. It's not that only I can do it — anyone can, but it needs the right mindset, continuous effort, and the acknowledgment that we need to learn, to experiment, to keep interacting with problems and exchanging ideas. Over time — whatever experience post my first job, be it Captain Fresh, or Informatica — whatever I've learned is never just one method, one feature, one product; it's always multidimensional, always at the intersection of research, math, business, science, and engineering.

Sometimes people don't agree with me. They demotivate, or disrespect my curiosity — "you can't get a research role, you can't aim at companies like Palantir, you can't aim at bigger companies." But you know what? I'm pretty confident that my intercept level — getting into a new problem, developing that belongingness, coming up with a baseline, understanding the situation — is around sixty to seventy percent. The remaining thirty is how much effort you put in: on the research side, on engineering, or on the mundane and boring work. Some roles demand a very nuanced research, which I could take up in a matter of time — not fundamental research, which needs more devotion, more discipline. But across these industries — research engineering, forward deployed engineering, applied AI, applied scientist, applied researcher — around seventy percent is a matter of time to get in, learn, and really solve. I don't claim I solve it in one pass, but I learn quickly, I come up with my own view. And that interdisciplinary thing helps — with a complex customer problem, or improving models and post-training approaches, or even new product ideas. It's all coming from that three years, eleven months — that great journey of decision sciences.

Now, personally, I'm perceiving that as decision engineering — trying to bring more mathematical, engineering, and scientific rigor to it. It's not coining something newer; it's my personal way of looking at things, my personal curiosity to do things better.

During my journey, it's not just connecting things, or wiring APIs or SDKs. Situations demanded creativity, research, the intersection of many things. At one problem, we were pitching hyper-personalization — a mix of extraction of objects, training models, search and reranking, building recommendations on top. In other places, it's agent-based modeling. Everyone is doing agents now — but we were among the very few companies with very early industrial adoption of probabilistic agents. It's more of a probabilistic, rule-based agent-based modeling, where you use probabilistic agents, or probabilistic models, plus business context, to simulate customer behavior. And how would you scale it, verify it? Now we have the evaluations problem — but back then we were already dealing with it: how would you evaluate simulations against reality, the trustworthiness. And there were problems at the intersection of computer vision and physics-based machine learning, where the forward pass was understanding the quality and defects of additive manufacturing, and the backward, the feedback loop, was why it's happening — relating it with cause-sensitive effects: a configuration issue, a design issue, overheating, the manufacturing environment.

So there were tons of problems that I and my colleagues got exposed to, at different scales — the systems level, a specific methodology, end to end, a specific research point of view. We were completely living in the customer problems, experimenting, exchanging, and evolving our knowledge. Now everyone says "organization brain" or "company brain" — and we had a very good setup, where all our past problem-solving was well connected, giving us confidence, and helping even a beginner gain real problem solving. It was the hands-on training, every Thursday's learning session, the customer visits, learning every day what your friends were doing — without any friction or envy. A wonderful time, and it set up a huge boost that continued in my further jobs.

That helped me see myself, and problems, from multiple angles — be it creating a new commoditizable product at the intersection of product and research, like at Captain Fresh and other startups; or Informatica, which was highly about friction and adoption, the behavioral aspects — understanding and encoding how humans solve the problem, into intuitions. And here at Nile, I use that knowledge across — building new systems, transitioning old-school ways into agentic, AI-native ones; or working on research problems and pushing myself toward independent publishing. And though I could simply get a job with my existing resume, I keep pushing myself to learn new problems, to recognize the beauty of problems from different angles, and to share the knowledge. It's all coming from those first three years. That's why I say our first job is beyond forward deployed engineering — and that experience has a lot to offer companies struggling with a forward-deployment strategy, or people who want to gain forward-deployed experience, or those interested in the new-age forward-deployed, applied, agentic roles.

Keeping your ground in research and entrepreneurship

One more thing — keep your ground in research and entrepreneurship. FDE is a very good place for recognizing research problems, improving them, and transitioning them. Sometimes the complex problems pave the way toward applied research, and toward improvement methods. Like I mentioned about position papers — if you keep thinking along those lines, rather than just adapting some repo or some paper's methodology, it gives a scope for research and further development. The real, hard customer problems are where the research questions come from — and, in the same way, where you start to see the ventures too. So keep your footing in both — the work itself is where the research problems and the ideas get recognized, and taken further.

How to think, learn, feel, and do your way in

Before I bring the actual roadmap — how to go about thinking, learning, feeling, and doing — I want to say it's multiple things. It's not a one-way thing, like "you watched videos, followed the tutorial, and built one or two projects for the sake of your resume." I don't agree that that's how we're taught.

I'll quote this from the book I've been reading now — The Way of Excellence, Brad Stulberg's new book. He asks: what exactly is acquired during skill acquisition? Skill is an adaptive functional relationship between an organism and its environment — he quotes it from a paper, Araújo and Davids' "What Exactly is Acquired During Skill Acquisition?" To put it differently: skill is not something you acquire; rather, it's something you sense and respond to — you feel your way through a complex environment.

Especially in contemporary AI — in research, in real-world problem solving, with too many people out there — the true leverage comes from how you sense and respond. Because even Palantir's line — living inside the customer's problem — a problem is an environment: it has its own nature, its own evolution, its own interactions. So that's why I want to put forth how you can simulate such an environment — through different dimensions: by thinking, by doing, by learning, by feeling.

If I could give you a mental model for how to look at AI forward deployment engineering: any problem, any solution, can be thought of as AI, plus computer science, plus system science, plus data science.

First, how do you think about the problem DNA? Take enterprise resource planning as a problem statement — different companies have different dimensions, different ways into it. So think about the problem itself: how many stages are there? What are the phases? Who are the people involved? Where does the data come in? What's the network of decisions — something upstream, another downstream? And from a systems point of view, how you dissect it into modules and interconnections — that really helps. Then translate it through AI elements: LangGraph, a directed acyclic graph, an ontology or knowledge graph. Because if you can represent a problem in an understandable abstraction, that helps you visualize the different elements — and for each element, what do you need: just an API call, or an agent, or something else? And if it's an agent, how do you build it?

So, three major elements, plus AI:

Computer science. How you build agents, program with SDKs, think about scaling, integrate the systems, the APIs — because at the end of the day, it's all a software package, with its own representation.

System science. How a problem is dissected into manageable modules, and how you map the system elements with the relevant solution elements. For planning, it might need different stages and loops, feedbacks or corrections — connected with whatever components you have, the ontology or context or agents. And if you think of agents and systems — I've written a blog on agents as complex adaptive systems — how an agent that lives in a problem space can adapt and improvise over itself. So at the intersection of computer science and system science, you think about how to construct a better agent design pattern, the harness, and how to improvise it over time.

Data science. Understanding the behavior; getting the evidence — whether it's breaking, whether there are issues or risks, and even the success and failure; everything proven from evidence. Think from a statistical or a simulation point of view. You've got three, four designs of a harness, or configurations of an agent — how do you validate? How do you say this is trustable, that it doesn't have a blind spot?

AI. The fundamentals: how reasoning works, how you build agents, how you build the harness so agents can self-improve, evaluations, and multi-agent. Sometimes people call a very stable workflow a multi-agent system, just because they define a different persona on each node. But a node in a graph isn't an agent — agency isn't graph topology. The way I think about it: an agent is identity, plus an owned goal, local state, a perceive-decide-act loop, and bounded authority — the authority to act, stop, or escalate. A workflow with a persona on each node has none of those boundaries; it's invoked, not autonomous. From there it's levels: a single agent (one agency boundary); a supervisor with sub-agents (the supervisor owns the final decision, delegates bounded goals, and integrates the results); and a true multi-agent system (multiple independent boundaries — each agent with its own role, state, and authority — talking over a message fabric and a shared knowledge graph, where peers can disagree, refuse, or escalate). This is close to multi-agent reinforcement learning, where each agent has its own outcome and they interact — cooperating, or holding their own commitments and context. In a finance-planning system, for instance, one agent handles evaluations, another planning, another stress-testing — each with its own workload, developed and evaluated independently, then tested on how they cooperate. But if an "agent" just runs step by step in a workflow, there's no real multi-agent coming in.

Let me make it concrete. Say the problem is a multi-agent system for medical document processing — evidence mining, chronological reporting, and downstream applications like mass tort tracking, side-effect surveillance, and personal injury claims. Here's how the four lenses look on the same problem:

Lens	On this problem
AI	The agents that mine the evidence and build the chronology; the reasoning to decide what to extract or verify next; evaluations so you can trust each extraction; and it's genuinely multi-agent — one for extraction, one for adverse-event cross-checks, one for the claims side.
Computer science	Build those agents, wire up the tools — OCR, the EHR system, a drug / adverse-event database — through SDKs, integrate the systems and APIs, and scale it to millions of documents. At the end, it's a software package.
System science	Dissect it into modules — ingest → extract → structure → chronology → the downstream apps — and map the interconnections and feedback loops. Think of it as a complex adaptive system: how the agents self-improve and adapt over time. This is where the agentic design pattern lives — defining each agent's persona, harness, and context, maintaining them independently, and the handoffs and coordination between them; plus the ontology of drugs, events, patients, and claims.
Data science	Get the evidence from the traces and the behavior; validate the extractions statistically; ask is it trustable, does it have a blind spot — a missed side-effect; and test it against reality.

Same problem, four lenses — and only once you see all four do you know, for each element, whether you need just an API call, a function, or a real agent.

And it's not always prompting and building agents — you might need different components. Sometimes you use existing tools, but sometimes the tools are very specific statistical functions, or data-science ones. If you're building an agent for life sciences, it might need to understand the business, the compliances, the medical or clinical nuances — some of it through reasoning, but a lot of it accessing the data, calculating the metrics, or spinning up a quick statistical model and comparing them.

Take building agents for data science work — it involves agents, functions, tools, workflows. Take that same medical-document system: an agent is a decision-making unit — the one that decides whether a batch of records needs entity extraction, an adverse-event cross-check, or a flag for personal-injury review. A function is deterministic — building a chronology from dated events, or running a fixed extraction model. A tool is a hook, an external connection — OCR on a scanned PDF, a query to a drug / adverse-event database, or pulling a record from the EHR. And a workflow is a predefined, reusable series of functions — the fixed extract → structure → validate → store pipeline every document goes through. It's just how you define it — not one method everywhere. You design it, understand the behavior through the traces, put it on LLM-as-a-judge or partial and formal verifications on the tool calls and outputs, and measure performance — how much time it takes, how much it wastes, whether there are a lot of distractions. Because whatever system you build now is not a deterministic one you can just spin up with a unit test and an integration test.

Most people start with learning SDKs, a whole tech stack. But what I'd suggest: start from practicing and visualizing with simple Python, or a pen and paper. When you have a problem, sketch it, press in the different elements, and then use the relevant things. If you can't write an agent loop in pure Python, use CrewAI, or LangGraph, or LangChain. For traces, Langfuse or MLflow. For reusable functions or workflows, Airflow, or a cron job, or plain Python. On a demand basis, search what's available, check the docs, follow that. So you always start with a good problem statement — sketch it, visualize how it works, list what you want to check and expect. This way, the learning is not cumbersome.

And another thing — we're not seeing enough. Take different verticals of your interest — CPG, banking, finance, operations research, life sciences — and learn what problems those companies solved in the past, and what they're interested in now. Build a bank of problems, and give yourself to learn about them. That way you get more ideas for projects and experiments — otherwise we all revolve around resume-level projects and tutorials, and don't think beyond calendar, meeting, or budget planning. And then, giving yourself a sense of creative, or scientific, thoughts: how do you evaluate an agent? How would you let an agent learn from its mistakes? How do you represent a context? How would you design the handoff from one agent to another? These need not be highly technical — first logical, and it can be creative.

There's more on the different elements. Within an agent there are different layers, a stack; and over the system, there are two things — the system, and the agents. A system can comprise multiple agents, workflows, a shared context, a shared memory. And within an agent, you have the harness, the tools. Sometimes, with coding agents, you design the harness so the agent can design or curate its own tools — but for that, you add skills. There are different views, like "thin harness and fat skills."

And these are all design patterns — because it's very behavioral and probabilistic, and it highly depends on the problem it interacts with. That's the fun, the scientific, aspect. If it were deterministic, you could say "this is the best way, this is the wrong way." But since it's probabilistic and behavioral, you do a forward pass and a backward pass in designing the agent — and let it improve, or tweak it. In the forward pass, from your logical or systems-thinking point of view, you design it so it goes and hits the problem; then from the traces, you improvise it — or let the agent improvise, by providing a meta-harness on top.

Resources. Read blogs and discussions from the AI Engineer community (ai.engineer) — a very good resource, because you get multiple perspectives: engineering, people who worked on real-world customer problems, and research. The LangChain and LangGraph blogs are really good; the DeepAgents harness is interesting; and you can always check Anthropic and OpenAI. You can also read about agents and LLMs through papers — position papers especially, because they let you think along those lines, rather than exactly adapting some repo or paper's methodology. Thinking along with a position paper might give a scope for research and further development.

Let your thinking take the first phase. When I was developing agents, I let my thinking take the first phase. Most of the time, you start with the tutorial — get a problem statement, Google it, put it in a chatbot, read through the papers. What I follow instead: if you have good fundamentals, use first principles. Think from a cognitive point of view, or data structures, or functional programming — "an agent is nothing but a while loop." Then figure out what's lacking, what's specifically needed for this problem. Make a checklist: does it need parallelization? Testing the behavior? A specific approach in evaluations, or in context? Do we need a semantic layer — because we might need to work on SQL, or access the data warehouses?

For a data science workflow, nothing is fixed. If you can't follow the graphical way of doing things — because any data science or statistical problem has step-by-step reasoning and judgment going hand in hand, hypothesis testing, analysis, checking assumptions — then it needs two elements. One is a dynamic way of writing functions or tools to test it out. And it's a curation: "right now we might check the power analysis, or run a linear model and get the interpretations, and based on that, check some other variables." All this, you can't thoroughly give through the workflow — you provide it through context and skills. In the skills, you share how to think about it, the possible situations, the elements to use. In the context, the business, problem, and data information. That's where semantics plays a role.

If it's experimental, or the data is available through CSV files, provide it as a data dictionary or catalog. On a broader problem — especially real-world evidence — the data is scattered in different tables, and the process and methods might be in different places; that needs a semantic layer and an ontology, for an agent to work on the data as well as the context. So ultimately, it's all about how you would solve the problem — because an agent is a replica of human intelligence; think of the parallels of artificial and human intelligence. And you can have your own approach, because it's a contained environment: you explore, experiment, evaluate, then move to the next stage.

It all reduces to basics. One might know all the tech stack — loop engineering, harness engineering, context engineering, graph engineering. But it's all fine, because it reduces to basic concepts if you come from a coding, or a data structures and engineering, background — similar to finite state machines, or directed acyclic graphs, or flowcharts and mind maps. And if you come from cognitive or behavioral science, you'd think about how agency is defined — how an agent decides on survival, or success. There's homeostasis — a regulation where every step, every adaptation is toward survival, toward prosperity. Even a bacterium — nothing sophisticated, but always oriented toward survival. So, from that point of view, an agent should be able to — even if it fails at the first pass — on the second pass, adjust itself: creating new tools, or adjusting the context: "we tried this, it's not working, it's failing into an error." I highly see that in the coding agents — that's something we use every day. So closely observe how they work: they write code, but they also change things; sometimes, without letting you know, they follow a specific pattern — "I might need to avoid this, or write this script." The same way, think of whatever agent ecosystem we develop — don't constrain it into a flowchart; give it enough freedom and a harness, and let it improvise. That's why I wrote in detail, in my blog "agents as complex adaptive systems," about how it evolves through adapting.

Systems thinking and design thinking. For business and customer problems, take a look at two perspectives: systems thinking and design thinking. Systems thinking gives you how to dissect and understand the problem in a systemic way — there's a small book called Thinking in Systems, which gives you representations, connectedness, feedback, buffers, all relatable to any business or social problem — and agents can be represented that way too. Design thinking gives you how to build the solution in an easily manageable, experimental, continuously improvable way. For both, you can follow a lot of YouTube tutorials — it might just need four hours to get started with how they help you work on customer problems.

Read the verticals — and what each one values. As you read about different verticals and problems — compliance, governance — you'll get to know the blind spots. In planning in enterprises — inventory, supply chain — the priority is decision quality: how trustworthy the decisions are. In life sciences, it's more about how compliant it is. Both are similar, but the importance is given differently. And personal, coding assistance is more about how well it's aligned and how correctly it solves. Depending on that, all the elements matter differently: coding assistance doesn't need neuro-symbolic reasoning, but supply chain, the real industries and enterprises, need ontology-based neuro-symbolic reasoning — an interpretable way of putting guardrails and verifications in place.

Sovereignty and model choices. It also depends on the customer's focus — whether they're interested in small language models. If they're petrochemical companies in the Middle East, they'd want everything on-prem, so you may not fully deploy the large models — you'd use smaller ones with agentic capability, and over time, if alignment or performance lags, maybe train one. But that's a long shot; I don't think many problems need it. Some platforms provide a shadowing kind of thing: let the larger model solve the initial phase, collect the data from traces, then train with RL so the smaller model gains agency. There are ecosystems — like Prime Intellect — that let you create verifiers and environments to validate and train such models. So it all depends on how much depth, sovereignty, or control the customer wants. Not everyone wants agentic-RL smaller models, ontology-based context management, or recursive self-improvement — some want something very deterministic, highly controlled. So you interact with customers, explore similar blogs, and see how much alignment you're seeing.

And unless you prove the value and the trust in real time, you can't simply dismiss your own thoughts ("nobody has implemented it"), nor accept some random tutorial just because it's highly viewed. Because, again and again — there is no one common method to solve everything. It's like a no-free-lunch-theorem kind of thing. So let your research mindset, your creative mindset, your skepticism be active — so it gives you an edge. Over time, as we keep trying that, it helps a lot.

The academia → real-world gap

This is really the gap between academia and real-world problem solving. So much of it, right now, is tutorials — many tutorials, many blogs — with a lack of the real difficulties, the real dimensions, of the customer problems. That's why we all revolve around similar resume-level projects, and we don't think beyond calendar planning, meeting planning, or budget planning. It's not just awareness of, or access to, the methodological corpus — "okay, it's easy to put this model in place, it's easy to use this platform." The gap is the real problem itself: living inside something interconnected and evolving, that doesn't arrive as a fully defined document. That's why the art of problem solving has to be practiced on real ground, not just studied.

What companies should adapt — training the forward-deployed talent pool

So, for companies — if you want to build a forward-deployed team, here's what I feel you need to adapt. The main thing: you don't assemble it by nitpicking people from the open market. You train a consistent school of thought, a culture, a way of approaching problems — from day one, at various levels.

Hire for the mindset, not the checklist — not just people who can code on Python notebooks, or who excelled at DSA, but people with the hunger to solve problems, to learn, to continually evolve, and the curiosity to keep going. Then operate on a belief system: learning over knowing, extreme experimentation, and an interdisciplinary perspective — continuing to interact with the problems.

Let people scale vertically as well as horizontally — deep into a problem space, and wide into prototypes, pilots, and business development — rather than getting saturated on one narrow thing. Build the org brain: connect all the past experiences, the past problem-solving, into a knowledge base, so that even a beginner can gain real problem solving. Trust the talent and nurture it — no hierarchies, where anyone can take up any work. And make it continuous: the hands-on training, the weekly learning sessions, the customer visits, and everyday learning what your colleagues are working on. That's how you train a pool — instead of nitpicking one.

Paths into FDE — journeys from every kind of start

If you're in the US, pursuing a masters, and interested in forward deployment, then a very good, balanced capstone project is one way. Use that opportunity to live inside the customer's problem — you can balance it toward very good design and implementation, as well as the research aspect.

Or, if you're already inside a company, working on internal things — you might want to move toward the customer side, rather than the internal problems. That needs a continuous showcase of interest: do some small experiments, show them to people, and collaborate with the people already working on it.

Let me tell you one thing. One of my close friends has been working on customer support for a platform — to really move toward a forward deployed engineering role, maybe at Databricks. He worked with a similar product, but as a customer support engineer, on bugs and the real problems that companies face. And from conversing with him, he has a better understanding of what problems customers face — in their data infrastructure, data cataloging, and downstream workflows. So what we were discussing is focusing on agents and analytics engineering: how data analytics and data science workflows can be developed with agents and semantics. Because that's what the Databricks Genie platform does — its own semantic layer, ontology. So building a similar approach, on a different customer side — the intersection of data analytics and agents, for life sciences, for manufacturing. He's focusing on a series of experiments and projects, in very focused areas, so he can really relate with the real problems that exist. He doesn't want to waste time building some meeting bots, or something unrelated.

All of these need additional skills, and curiosity toward different domains, schools of thought, and scientific things. Because building AI systems, being someone interested in AI, in FDE, is not just software or systems engineering; it has behavioral elements, it has AI and LLMs, and it has these different verticals and problem spaces. And if someone is interested in cognition, complexity science, that might help them improve the way they design and test their agents. So these are emergent curiosities — and it depends on how we embrace and interact with things.

Emergence — wholeness, and why every slice of AI matters

Over this whole journey, I've come to see it as a kind of emergence. I keep learning, exploring, figuring out emerging skills — and a curiosity toward science and engineering, cognition, complexity science. And it gets nurtured further by my control-systems background — it paved the way into management, engineering, and the science aspects; it kindled the reading; it kept improving the thought process. What comes out of it is a wholeness in the career, and a better view of it. And that wholeness is an effective way of building a career toward excellence, and toward value creation in the AI era.

And in this era, every aspect of AI is equally important and valuable. Before AI, a data scientist at a service company had lesser leverage than someone at a product or an enterprise company. But now — be it FDE, RE, RS, product engineering; or post-training, safety, evaluations, security, policy, governance; for governments, for data, for infrastructure, for modeling — take any slice of AI, and it carries equal importance for research, for engineering, and for real-world problem solving and impact. So the leverage has changed. And that's why the wholeness matters — you're not stuck in a lesser slice anymore; every slice is a place to do research, to engineer, and to make real impact.

Immersion and interaction — the craft

The craft comes from immersion and interaction. Reading — going deep into the problem and the field. Exchanging ideas — the back-and-forth with people, the Socratic dialogue. Small experiments — trying things, testing them, keeping a champion and a challenger. And thinking aloud — putting your thoughts outside your head, and brainstorming against them.

None of it is a finished thing. The craft develops as you keep at it — as you keep practicing, and keep trying different patterns of building. That's what really helps you out. So immerse yourself in the problem, and keep interacting — with people, with ideas, with the problem itself.