AX isn't adoption — it's how the company runs. Answers to the questions everyone asked

Last week I posted a short note on Threads.

Meta has an org that does nothing but AX. I'm lucky enough to work there as a tech lead (TL). Ask me anything — I'll answer as much as I'm allowed to.

Within two days it had been read more than 48,000 times, with over a hundred questions and comments. An AI engineer doing AX at LG Electronics, a planner at a web agency, a game-studio developer, in-house forward deployed engineers, AX educators, startup leaders — different seats, different worries.

But laid side by side, the questions were asking the same thing in different languages. This post groups them and answers again. Questions are paraphrased and merged; answers expand on what I actually wrote in the thread.

The conclusion, up front: AX is not an AI adoption project. It is a redefinition of culture and operating process. Everything below is a footnote to that sentence.

AX is systems design

Q. How do you define AX?

Designing systems so that agents can take over much of what people used to do, and building the human-agent interface. It is not buying tools. It is not running trainings. It is redesigning the structure through which work flows.

Q. IT, DX, AI, AX — so many terms. How do you tell them apart?

In the US — at least around me — nobody uses any of these words. Oddly, "AX" seems to exist only in Korea. What matters is not the vocabulary but the core of the problem. If you can answer "which bottleneck in our org will agents remove," what you call the work is irrelevant.

Q. What does Meta AX actually work on? Is the team a builder or a supporter?

All of it. Harness, memory and context, tooling, infra, applications, and forward deployed engineers embedded in teams. The teams investing in shared infrastructure and the teams helping each department talk to each other and build one roadmap together. The in-house FDE job in one line — helping each team hit its own success metrics.

Not a technology rollout — a process change

Q. Should we appoint AX champions, or should the AX team embed itself?

AX is less a technology rollout than a process change. It is closer to culture. That is why leadership direction matters more than "AX champions." You need leadership willing to take the risk of adopting AI-native ways of working even when it creates short-term inefficiency.

Korea still runs on .hwp files, for example. You will struggle to pull off AX innovation while insisting on hwp. Leadership saying "from now on, reports come in markdown — and we improve from there, one step at a time" — that single decision does more than ten champions.

Q. Where do we even start?

Define the goal first. Find the bottleneck in how problems get solved, then decide how to improve it. "One decision used to take five people at least ten hours — how do we change that process?" Questions like that are where AX begins.

The target is also predictable: the pain point everyone feels, and specifically the work people know is necessary but can't be bothered to do. Solve that, and the internal response is at its best.

Q. How does an internal agent get started and spread?

Concentrated investment, usability, and branding. The most important thing is finding people's single biggest bottleneck and designing for it first. Telling non-engineers "just use Claude Code" only goes so far.

And I believe every company eventually needs its own harness. A third-party harness will always fall short on integration with first-party tools and on behavioral control. That is where internal agents start.

Q. Is this different from traditional process-innovation consulting?

Not fundamentally. The problem-solving is similar. The difference is refusing the template — making bolder, more flexible attempts, faster. Same for how the AX team compares to a classic engineering team: broadly similar, but more open and more daring. Try quickly, change quickly, keep what works.

The end goal is value creation

Q. How do you set success metrics for AX?

Ultimately you measure business impact. Every company has topline business metrics. The clearest one is revenue — every business exists to create profit, and the other topline metrics are proxies for it.

Q. What about "fake adoption" — high tool usage, unchanged output?

It is real. Second Brain and Obsidian are the obvious example. The moment the knowledge graph renders, many people feel "I'm AI-native now, my productivity went up." Adoption was high. And it isn't wrong — a personalized knowledge graph is becoming table stakes for context engineering. But having one does not make everyone more productive.

The end goal is value creation. How much did end-to-end delivery time drop. How many meetings disappeared. How much did product quality rise. How much more revenue with the same headcount. Impact metrics, not adoption metrics, are what count. They are hard to measure — and designing that measurement is itself part of AX.

Q. And when impact refuses to show up as a clean number?

That is exactly why AX is hard. When impact is hard to measure, fall back to two things: how much time you saved, and how much resource — people and money — you saved.

Q. Without visible wins, isn't this just a cost center?

That is precisely why the org exists. Meaningful wins do exist — but they are partial. The focus now is on ways the entire company can transform.

AX has no "after"

Q. How do you handle maintenance after AX? Things break even after automation.

I would push back on "after AX." AX is not a one-and-done project. The true end state of AX is a human-on-the-loop system: agents drive most operations and decisions, and humans step in only when genuinely needed.

So the real question is not maintenance but the feedback loop — how do you build a system that improves itself. The failure cases people call "maintenance" should already be designed into the AX system. The moment someone says "these report numbers look off," an agent should pick that up, improve the system itself, and route the change to a human for approval. That is the design surface.

Q. How do you evaluate agents in production?

You need both online and offline evals. We also run qualitative evals (UXR). User feedback loops and in-app surveys matter as much. The evidence for improving an agent comes from this evaluation system — and design questions like "should this split into multiple agents" start from how you define evaluation, too.

Q. Every model update collides with the existing harness. What then?

You re-carve the harness. A harness is not an asset you build once — it is a living system you keep carving alongside the model.

Standards and quality are the central problem

Q. Developers and designers resist vibe-coded output.

That is a quality-control and culture problem. I rarely see developers dismiss vibe coding anymore, and the holdouts will soon have little choice. Design is heading the same way.

Two things matter. First, the standard by which quality is judged — objective and scalable. Second, how the development process changes and adapts. When the first is solid, the second gets easy: with clear standards, anyone can build and propose regardless of role. If review costs balloon in the process, redesigning the process to cut them is the second job.

Q. Every team builds its own tools and skills. It's chaos.

When everyone runs different skills and tools, quality control drops, resources scatter, and you create a bigger bottleneck: understanding and reviewing everyone else's output. Company- or team-wide plugins (harness, hooks, skills, memory) and standardized process — design goes through this skill, review works this way — are non-negotiable. Building the standard and the quality bar, then investing heavily in them, is the central task of AX.

Q. What about data access and security?

Security and privacy are among the hardest problems in AX. More information always helps — but that does not mean you get to use all of it. Passing reviews and verification, and building products and processes users can accept, is difficult and important in equal measure. Here, too, leadership's stance is what decides.

Q. How do you remove the "AI feel" from AI-written text? Agent output still needs so much fixing.

Same answer for both: harness engineering — carving rules, skills, context, and hooks well. Give the model exact instructions and examples. It is the same principle as saying "remember not to do this — save it to memory" every time you fix a mistake. In the end it is prompt engineering, and the accumulation of it is your harness.

Q. Be honest — you learn all this from AI, right?

Of course. But AI does not teach you everything. Building and carving a solution grounded in your actual situation, your existing processes and operations, and your domain knowledge — that process stays human-centered.

In the end, you are solving people problems

Q. Isn't AX a dead-end career, removed from core technology and core business?

The exact opposite. AX is business operations itself. AX that ignores the core business is misdirected from day one. Nor can you cap its scope or deadline — the end state is full agent automation with human-on-the-loop design, and that is no easy goal. Which is why AX capability comes from understanding business and people.

Q. What career path leads to an AX tech lead role at Meta?

Roughly three things.

1. Track record and reputation — I am nine years into Meta, all on one team. I worked hard and was lucky enough to land results more than once.
2. Risk taking and AI-native — I came from the ads org. But I kept betting on AI and agents: taking on work outside my team's scope, writing, building plugins, and selling the work hard inside the company.
3. Leadership and action — in AI, experts are everywhere and nowhere, because this is a new problem for the entire industry. I tried to take hard problems, stay on them with focus and persistence, and gather passionate people to solve them well.

Q. What matters most when building an AX team?

No single right answer, but leadership first. Then domain knowledge. Then everything under the umbrella of problem-solving — intelligence, persistence, passion, boldness, communication.

Q. I want to do AX at a global tech company. Does English come first? Research depth or field experience?

AX is closer to solving culture and people bottlenecks than to technology. So English and communication skills are mandatory — if you cannot persuade your client, you can do nothing. Today's AX needs process, domain, and business understanding more than it needs technical depth.

Q. How do you handle resistance from people whose job security AX threatens?

It is not an easy problem. But anxiety and fear are not reasons to look away from reality.

Q. What should an ordinary developer aim for?

The goal has not changed. Fail more (learn more), attempt more, achieve more.

The other side of the one-click button

The question I remember most: "Soon there will be an AI that does everything in one click. What are AX people preparing for, personally?"

My answer was short. We intend to build that one-click button better.

One-click buttons do not appear on their own. Someone finds the bottleneck, sets the standard, carves the harness, designs the feedback loop — that is what makes the button exist. The better the button gets, the harder and more important the design behind it becomes.

The end state of AX is not a company that uses AI well. It is a company where agents run most operations and decisions, and people step in only when it truly matters.

That company does not exist yet.

We are building it.

---

The original Q&A lives in the August 2026 Threads AMA. Questions are paraphrased and merged; no questioner identities are included.