I remember looking at hotel inventory in Singapore and realizing that, inside an online travel agency, or OTA, platform, a room is not really a room.

To the guest, it is a weekend stay, a small escape, or a family decision. To the platform, it is content. And if that content is not connected, updated, trusted, and distributed, it does not matter how good the room is.

That is a lesson I keep relearning in different industries.

Great content matters. Great supply matters. Great products matter. But until they are distributed well, they remain potential energy.

A hotel room is not just a room. Inside the travel tech value chain, it is content. An OTA needs content so guests can discover, compare, trust, and book. The more unique and reliable that content is, the stronger the platform becomes.

But content does not move by itself.

To make a room bookable, the OTA needs connectivity. Hotels use property management systems and channel managers. Rates, availability, room types, restrictions, packages, photos, policies, and inventory need to move constantly between systems. If this layer is weak, even good supply becomes invisible or unreliable.

That was one of the lessons I learned while serving as the Chief Technology Officer (CTO) of a new OTA player in Singapore.

During that period, Singapore Tourism Board launched the SingapoRediscovers Vouchers program. It was a simple idea with a lot of operating depth behind it. Give citizens digital credits, make domestic tourism more accessible, and stimulate the local tourism economy when international travel was heavily restricted.

I still think it was a strong strategy. It did not only create demand. It distributed value.

For the campaign to work, hotels, attractions, tours, packages, payment flows, voucher redemption, and user discovery all had to connect. Traveloka, as one of the authorized booking partners, described more than 100 hotel inventories, over 1,000 room types and packages, more than 100 attractions and tour partners, and over 200 experiences available to users through its platform.

That is not just marketing. That is infrastructure becoming visible to the end user.

The user sees a voucher and a booking flow. Underneath it, there is supply aggregation, content freshness, platform trust, campaign design, partner onboarding, and distribution.

This is where I think many founders, including myself at times, underestimate the importance of distribution.

We like to believe that if the content is good enough, people will find it. Sometimes they do. Most of the time, they do not. Value needs a path. Content needs connectivity. Supply needs access. A platform needs distribution.

Earlier this year, I built an open source project called VisitKorea AI MCP Hub, released under the MIT license.

The motivation came from a similar pattern.

Korea has rich tourism content. The Korea Tourism Content Lab, built by the Ministry of Culture, Sports and Tourism and the Korea Tourism Organization, is a digital tourism content platform that brings together tourism information, images, videos, and other assets. It contains around 700,000 records, including multilingual tourism information and high-quality images, and makes them available through APIs.

That is valuable content.

But in the AI agent era, I do not think availability alone is enough.

If tourism content is going to reach the masses, it needs to be available through the protocols and interfaces that modern builders and AI agents actually use. It needs to be easy for an agent to search, retrieve, reason, plan, cite, and produce something useful for a real person.

That is why I built three MCP servers.

The first is the general VisitKorea tourism MCP server. It gives AI agents access to tourism information such as attractions, regions, places, images, and destination details. This is the base layer for discovery.

The second is the medical tourism MCP server. It focuses on Korea’s medical tourism information, including clinics, hospitals, specializations, and foreign-patient-oriented services. This matters because medical tourism has different trust, context, and decision requirements than leisure travel.

The third is the wellness tourism MCP server. It exposes wellness destinations such as spas, healing centers, meditation, nature-based experiences, and wellness-related facilities. This is important because wellness travel is often less transactional. People are not only looking for a place to visit. They are looking for recovery, balance, and a certain emotional state.

Together, these servers turn static public data into something an AI agent can actually use.

I saw this become real in two use cases.

The first was when I was planning a trip to invite a Saudi conglomerate to visit Korea. This was not a casual itinerary. The context mattered. The trip needed to respect business expectations, cultural fit, time constraints, hospitality standards, and the kind of Korean experience that would feel both premium and meaningful.

A generic travel plan would not work.

The agent had to think through who the guests were, why they were coming, what kind of impression Korea should leave, and how the schedule should balance meetings, cultural exposure, food, rest, and movement. The content needed to be curated, but the distribution layer made it possible for the agent to assemble the plan quickly from reliable data.

The second use case was more personal.

A former colleague of mine, originally from the United States, had never visited Korea. He was planning to come with his family and had a young child. The criteria were completely different.

This was not about executive hospitality. It was about comfort, pacing, child-friendly experiences, jet lag, food choices, hotel location, airport transfers, and avoiding the mistake of over-planning a family trip.

The agent helped create a full travel plan that considered those constraints. It used the MCP servers to gather source-backed tourism and wellness information, then produced a ready-to-use PDF itinerary that the family could actually carry into the trip.

That was the moment the pattern became clear again.

The value was not only in the data. The value was in bringing the data close enough to the user’s real decision.

A family does not want an API. A business guest does not want a database. A traveler does not want 700,000 records.

They want a plan that fits them.

This is where AI agents can create immediate value. Not by replacing the travel industry, but by connecting parts of the value chain that are still too far apart.

Public data is often far from the user touch point. Hotel inventory is far from emotional intent. Wellness content is far from actual recovery. Medical tourism information is far from trust. APIs are far from decisions.

The opportunity is to close that distance.

That is what distribution really means to me now.

It is not only paid ads, SEO, SEM, campaigns, or performance marketing. Those matter. I have seen how much they matter. But distribution starts earlier than marketing.

Distribution starts when value becomes reachable.

In travel, this means fresh inventory, channel connectivity, searchable content, trusted booking flows, and clear user journeys. In AI, it means modern protocols, agent-ready tools, useful schemas, and workflows that produce outcomes instead of raw data.

The founder lesson is simple, but not easy.

Do not confuse having value with distributing value.

High-quality content is important. But if it cannot travel through the right channels, into the right tools, at the right moment, for the right user, it stays locked inside the system.

Content is the asset.

Distribution is the path.

And in most markets, the path is still where the company is built.

There was a point while building Agent CMO when I realized the hard part was no longer getting an AI to write code.

The hard part was giving the work enough structure so the speed did not create more problems than it solved.

That realization changed how I used coding agents. The future of software engineering is not only about asking AI to write code faster. It is about learning how to manage intelligent work.

When I started building Agent CMO, I did not want another marketing tool that generated a few headlines and called itself an AI product. I wanted to build an AI-native marketing operating system that could take a brief, reason through the strategy, produce campaign assets, review its own work, learn from performance, and help decide what to run next.

In other words, the product itself had to work more like an organization than a feature.

The same was true for the way I built it. I had to stop treating coding agents like autocomplete and start treating them like junior engineers, analysts, reviewers, QA specialists, and implementation partners. The quality of the output depended less on the model and more on how clearly I designed the work.

I was partly influenced by an X/Twitter article from Ryan Sarver that was well received because it did something useful and rare. It did not talk about AI agents in vague terms. It explained a real workflow from the perspective of someone actually using agents to extend their operating capacity. The structure was simple and effective: start from a real constraint, show the system that was built, explain the workflow, then share the lessons that other builders can reuse.

That is the spirit of this post. This is not a theoretical essay about AI. It is a builder’s note on what I learned developing Agent CMO, and how software engineers can use coding agents more effectively.

The first mistake is asking an agent to build the product

The worst prompt you can give a coding agent is to ask it to build a complete AI marketing platform.

It feels ambitious, but it is actually lazy. The agent has no product judgment, no sequencing, no architecture context, no acceptance criteria, and no reason to know which decisions matter most.

Early in the process, I forced myself to plan Agent CMO as an orchestration system before thinking about screens or database tables. The initial planning exercise defined the product around a master agent and a set of specialized sub-agents. The important design principle was clear: do not let production agents create assets before strategy agents have locked the brief, audience, positioning, and channel plan.

That principle became one of the foundations of the product.

If you allow content production to happen too early, the system can generate a lot of material quickly. But much of it will be generic, inconsistent, or hard to use. The strategy has to come first. The brief has to become structured data. The audience has to be defined. The positioning has to be sharpened. The assumptions have to be named. Only then should the system produce campaign assets.

This is also how coding agents should be used. Do not ask the agent to write code before you have clarified the architecture, dependency order, success criteria, and constraints.

Agent CMO is built as a coordinated AI workforce

At a high level, Agent CMO is a multi-agent AI marketing operating system. The user drops in a campaign brief, and a coordinated team of 18+ specialized agents researches, plans, writes, designs, reviews, packages, and learns from the campaign.

The master agent acts as the orchestrator. It does not try to do every job itself. Its responsibility is to manage the workflow, maintain the campaign context, enforce dependency order, and route work to the right sub-agent at the right time.

That matters because marketing work is not one task. It is a chain of dependent decisions.

The Brief Agent reads the user’s input and turns it into structured campaign data. The Market Research Agent looks at the market, trends, threats, and opportunities. The ICP Agent defines the target customer in detail. The Positioning Agent sharpens the message and unique value proposition. The Channel & Funnel Agent maps the channels and customer journey. The Assumptions Agent names the core bets and gives each one a disproof condition.

Only after that strategy layer is formed do the production agents begin their work.

The Content Strategy Agent creates the campaign calendar. The Copywriting Agent writes headlines, social posts, calls to action, and core campaign copy. The Creative Direction Agent sets the visual and tonal direction. The Paid Media Agent builds ad variants for platforms such as Google, Meta, and LinkedIn. The Email Agent creates a five-step nurture sequence. The Prompt Engineering Agent produces prompt packs for image and video tools.

Then the governance layer checks the work.

The Brand QA Agent looks for brand drift. The QA Agent checks accuracy and quality issues. The CRO Agent looks for missed conversion opportunities. The Performance Agent projects reach, CTR, CPA, ROI, and prioritized A/B tests. The Memory Agent stores brand voice and learnings across campaigns. The Experiment Agent turns real results into the next campaign hypothesis.

The point is not that each agent has a clever name. The point is that each agent owns a bounded job.

That is what makes the system useful.

The product had to learn, not just generate

A lot of AI products still behave like disposable chat sessions. You ask for something, receive output, copy it somewhere else, and lose the context.

Agent CMO was designed around a different loop.

The platform takes in a brief, runs a nine-stage agent pipeline, produces reviewed and packaged assets, accepts real performance data, extracts learnings, and proposes the next experiment. The campaign does not end when the copy is generated. It continues into monitoring, learning, and iteration.

This is why the Memory Agent and Experiment Agent are not optional features. They are part of the core product philosophy.

A marketing system should remember what worked. It should remember what failed. It should remember approved brand voice, killed assumptions, audience insights, and lessons that should shape the next campaign. Otherwise every campaign starts from zero again.

That was one of the main product decisions behind Agent CMO. The value is not only speed. Speed matters, but compounding context matters more.

How I planned the development work

The development process followed the same logic as the product.

Instead of asking a coding agent to build the whole application in one pass, I separated the work into ordered workstreams. This applied whether I was working through coding agents directly, using Replit as part of the development environment, or reviewing implementation details myself. Each workstream had a clear purpose, a set of files or components it was allowed to touch, and a definition of what completion looked like.

The initial planning focused on the agent architecture, the master-agent orchestration model, and the major capability groups: strategy, channel planning, creative production, governance, intelligence, and memory.

The later continuous development plan broke implementation and integration work into more practical streams. There were separate workstreams for pipeline implementation, API and database behavior, form and input validation, frontend and UI flows, admin access control, homepage SEO readiness, performance bottlenecks, and security checks.

This sounds obvious, but it is where many engineers lose time with coding agents. They give one large instruction, receive a large diff, then spend hours trying to understand what changed.

I prefer a different pattern.

Give the coding agent one meaningful unit of work. Tell it the context. Tell it what not to change. Ask it to produce a plan. Review the plan. Let it implement. Then verify the implementation with tests, logs, type checks, screenshots, or manual inspection. In environments like Replit, this discipline matters even more because the agent can move quickly across files, dependencies, and runtime behavior. Speed is useful only when the scope is controlled.

That workflow feels slower at first. It is faster over a real project.

The architecture also had to support agentic work

Agent CMO is implemented as a pnpm monorepo with three main artifacts behind a path-routed reverse proxy. The web application runs on React, Vite, Tailwind, and Wouter. The API server runs on Express, Node, Drizzle, and Postgres. A separate mockup sandbox supports component preview work.

The shared libraries matter because they reduce drift. The database schema and Postgres client live in one shared library. The OpenAPI contract generates React Query hooks and Zod schemas. Provider integrations are separated into their own packages for OpenAI, Google Drive, Dropbox, Clerk, and other external services.

That structure was important because agentic applications need clear boundaries. If everything is mixed together, the coding agent has too many ways to solve the same problem. That creates inconsistent patterns, duplicated logic, and fragile integrations.

A good codebase gives the agent fewer places to be clever.

The pipeline jobs are persisted in the database and executed by an in-process worker inside the API server. Authentication and approval are handled through Clerk. Campaign files can route through app storage, Google Drive, or Dropbox, depending on plan permissions and user OAuth state. Admin users can manage pricing plans, approvals, CMS pages, payment gateways, social links, and pipeline queue visibility.

None of these decisions were just implementation details. They shaped how reliably the agent pipeline could operate as a product.

What worked best when using coding agents

The most important lesson is that coding agents perform best when the engineer behaves more like a technical lead than a prompt writer.

You cannot outsource judgment. You can outsource execution, exploration, refactoring, test generation, scaffolding, documentation, and code review support. But you still need to decide what matters, what order things should happen in, and what trade-offs are acceptable.

Several practices consistently improved output quality. Start with architecture before implementation, because agents produce better code when they know the intended boundaries and dependency order. Break work into separate workstreams, because smaller scopes reduce unintended changes and make verification easier. Write acceptance criteria before code, because the agent needs to know what success means before it starts changing files.

Separate strategy, production, and review tasks. The same agent session should not plan, build, and approve its own work without checks. Use the codebase’s existing conventions, because agents are much stronger when asked to extend patterns instead of inventing new ones. Verify every meaningful change, because type checks, tests, screenshots, logs, and manual review are still the engineer’s responsibility. Keep memory outside the chat when possible, because durable files, specs, TODOs, and implementation notes prevent context loss.

The last point is especially important. A long chat history is not a reliable engineering system. I found it much more effective to maintain explicit planning files, workstream files, verification notes, and constraints that could be reused across sessions.

That is also why the Agent CMO product itself emphasizes structured envelopes, campaign reports, memory, and transparent stage status. Durable context is what turns one-off generation into an operating system.

The best coding agent workflow mirrors a good engineering team

A strong engineering team does not throw every task into one Slack message and hope for the best. It separates discovery, architecture, implementation, review, QA, release, and monitoring.

Coding agents need the same discipline.

When I used agents effectively, I usually followed a consistent sequence. First, I asked the agent to read the relevant files and summarize the current behavior. Then I asked it to propose a minimal implementation plan before editing code. After that, I asked it to identify exactly which files should change and which should not.

Only then did I let it implement the smallest coherent change that satisfied the plan. After implementation, the work had to be verified through checks, inspection, and evidence. The final step was documentation and handoff, which meant updating the relevant README, API contract, implementation note, or next-workstream instruction.

This pattern helped prevent the most common failure mode: impressive-looking code that does not actually fit the system.

Coding agents, including agentic development environments such as Replit, can write and modify code quickly. That is not the hard part anymore. The hard part is directing the work so that speed does not create architectural debt.

What I would tell software engineers building with agents

If you are a software engineer using coding agents, do not measure success by how much code the agent writes. Measure success by how little confusion the agent creates.

The best agent sessions have a clear task, a clear context window, a clear output, and a clear verification method.

I would treat every coding agent instruction like a ticket for a capable but unfamiliar teammate. Give the background. State the goal. Define the constraints. Point to the relevant files. Explain the expected behavior. Ask for a plan before implementation. Then review the result like you would review any pull request.

If the agent makes a mistake, do not just correct the code. Improve the instruction system that allowed the mistake. Add a convention. Add a test. Add a note. Split the workstream. Narrow the scope.

That is how you get better over time.

Agent CMO is also a lesson in product design

Building Agent CMO reminded me that AI-native applications are not defined by having a chat box. They are defined by whether the system can take responsibility for a meaningful workflow.

A real AI-native product should have memory, task ownership, review loops, structured outputs, orchestration, and a way to improve from feedback. It should know when to run tasks in sequence and when to run them in parallel. It should expose what it is doing so the user can trust the work. It should produce assets that are ready to use, not just interesting to read.

That is the bar I tried to hold Agent CMO to.

The product starts with a brief, but it does not stop at generation. It researches, plans, produces, reviews, packages, monitors, learns, and recommends the next experiment. The master agent keeps the whole workflow coordinated, while the sub-agents focus on their individual responsibilities.

That is also the way I now think about working with coding agents.

Do not ask one agent to be brilliant at everything. Build the system around clear roles, clean handoffs, and real verification.

Software engineering with agents is not less disciplined than traditional engineering. It is more disciplined, because the cost of vague direction is now multiplied by speed.

The opportunity is enormous. But the advantage will not go to the engineers who prompt the most. It will go to the engineers who can design the work.

I remember first coming across the academic concepts and definitions of short-term and long-term memory around 2000, through my friend Junchol Park, whom I usually call JC.

JC is a domain expert in data science and neuroscience. During his undergraduate years, he introduced me to what he was learning through his coursework and lab experiments, especially around how different parts of the brain serve different functions related to memory.

Some parts helped us process immediate signals. Some parts helped us retain patterns. Some parts helped us coordinate movement, judgment, language, emotion, and memory. What stayed with me was not only the biology, but the architecture.

The brain was not one monolithic intelligence engine. It was a system of specialized modules, coordinated through signals, context, and repetition.

I remember one subway ride when I mentioned to JC that I could imagine a kind of digital brain, not as a metaphor only, but as a system and software layer where people could dump their short-term and long-term memories, then retrieve them on demand.

Intelligence without memory is not enough.

When OpenClaw first went viral, I started looking at it from a system architecture perspective. I wanted to understand how its components were organized, how it shaped the developer experience, and why it resonated so quickly with the community.

A fellow developer community leader and entrepreneur, Jason Kneen, was also actively posting on X/Twitter about OpenClaw and its architecture. His posts helped me speed up my own understanding. Sometimes the best way to learn is not just through documentation, but through the lens of another builder who is taking the time to explain what matters.

And earlier this year, I was also inspired by several developers talking more actively about persistent memory for AI agents. That brought the old idea of a digital brain back into a more practical frame. Not memory as a vague concept. Persistent memory as infrastructure.

Most AI agents today still behave like they have impressive short-term memory and fragile long-term memory. A context window can hold a conversation, a task, a document, or a decision for a limited period. But once the session ends, the agent often loses the thread unless the platform has its own memory layer or the user manually restates the context.

For casual use, this may be acceptable. For real work, it becomes expensive.

A founder does not want to re-explain the same product strategy every week. A consultant does not want to restate the same client constraints across tools. A developer does not want to remind every agent which architecture decisions were already made. A team does not want business knowledge scattered across prompts, folders, Slack threads, cloud drives, and disconnected AI sessions.

This is why I built Agent Memory Dump earlier this year.

Agent Memory Dump is an MCP memory server designed to act as a shared memory layer across multiple AI agents. It stores conversation turns, prompts, responses, tool calls, decisions, and code as structured observations in PostgreSQL. It groups those observations into sessions, tags them by agent and timestamp, and makes the memory available through MCP tools so different agents can read and write to the same store.

The important part was not simply saving text. The important part was making memory searchable, portable, and reusable.

The system uses hybrid search, combining full-text search, vector similarity through pgvector, and recency weighting. It also creates session summaries so long histories can remain useful without flooding the context window. In practical terms, this means an agent can retrieve relevant past work even when the wording has changed, even when the memory is old, and even when the full history would be too large to load.

That solved one problem I was feeling personally: my agents needed a shared memory dump.

If I moved between Claude Desktop, Manus AI, and OpenClaw, I did not want each one to behave as if it had never met me before. The memory layer needed to sit outside the agent, not inside a single platform.

That was the first pattern.

Memory should not belong to one interface.

After the Easter holiday, I started building and testing a new project called SourceMind.

At first glance, SourceMind may sound like another AI search tool for cloud storage. But for me, it came from a very specific realization.

Agent memory is not enough if the underlying reference sources are still fragmented.

It is useful for an agent to remember what I instructed it to do. It is useful for an agent to remember the responses it generated. It is useful for an agent to recall decisions, summaries, and past workflows.

But much of our actual work does not live inside the agent conversation.

It lives in PDFs, pitch decks, spreadsheets, contracts, strategy notes, CSV exports, JSON files, client folders, Dropbox archives, Google Drive structures, and documents created years before the AI agent entered the workflow.

So I needed a second layer.

SourceMind is an AI intelligence layer designed to unify and interrogate data across fragmented cloud storage ecosystems. It connects to Google Drive and Dropbox, lets users browse folders and select files or entire folders for indexing, then processes those files through an ingestion pipeline. PDFs, text files, CSVs, and JSON files are chunked, embedded, stored with pgvector and full-text search vectors, and made searchable through hybrid retrieval.

The user can then ask natural-language questions and receive cited, RAG-powered answers linked back to the original documents. That citation layer matters.

A generic agent response may sound confident, but confidence is not the same as traceability. If an answer is based on a source file, I want to know which file, which passage, and which context shaped the response. For serious work, especially in consulting, enterprise transformation, finance, education, hospitality, logistics, or regulated environments, traceability is not optional.

SourceMind also handles the operational layer around this problem. It supports OAuth connections to cloud storage, encrypted tokens at rest, background indexing jobs with status and retry logic, audit logs, and administrative visibility. These may not be the glamorous parts of AI, but they are the parts that make the system usable beyond a demo.

This is also why SourceMind is different from simply activating a Google Drive connector inside one AI agent.

A connector gives one agent access to one storage environment within that agent’s workflow. That can be convenient. But convenience is not architecture.

SourceMind is built as a centralized intelligence layer. It is designed to sit across storage providers, selected folders, indexed files, search methods, citations, and audit trails. It can become a shared retrieval foundation for multiple agents, workflows, and business use cases. Instead of asking one AI tool to temporarily inspect a drive, SourceMind prepares the knowledge layer so agents can operate on a more reliable foundation.

That distinction matters because AI augmentation is not only about prompting better. It is about preparing the system around the prompt.

When I think back to that early conversation with Junchol, I realize why the brain remains such a useful metaphor.

The brain does not treat intelligence as a single function. It has different areas and systems that influence memory, movement, judgment, emotion, perception, coordination, and action. These areas do not operate in isolation. They interact constantly. They receive signals, interpret context, strengthen pathways, and help us respond to the world.

In system architecture terms, you could call them modules or components. In product terms, you could call them layers of experience.

The AI platforms and agentic user experiences we are building today are beginning to mirror that structure. We have model layers, memory layers, tool layers, retrieval layers, orchestration layers, interface layers, permissions layers, and audit layers. Each one serves a different purpose. Each one changes what the user can trust the system to do.

A model without tools can speak, but it cannot act very far.

A model without memory can assist, but it cannot build continuity.

A model without retrieval can reason from its training, but it cannot reliably use the user’s current operating reality.

A model without auditability may be impressive, but it becomes difficult to deploy in serious environments.

This is why I believe the next wave of AI-native businesses will not be built by simply attaching an LLM-powered chatbot to existing workflows.

They will be built by preparing the data, memory, retrieval, and orchestration layers around the business itself.

Whether the industry is hardware manufacturing, fintech, edutech, hospitality, logistics, professional services, or any other vertical, the challenge is similar.

Most organizations want AI augmentation, but their knowledge is scattered. Their files are fragmented. Their decisions are undocumented. Their workflows depend on tacit knowledge. Their data lives in different platforms, owned by different teams, with different levels of freshness and quality.

Then they ask an AI system to behave intelligently.

But intelligence depends on what the system can see, retrieve, remember, and verify.

This is where founders and operators need to become more disciplined. The work is not just choosing the latest model or adding another AI feature. The work is preparing the organization so AI has something coherent to augment.

That means building reference sources. It means deciding what should become persistent memory. It means designing how agents access files, how answers are cited, how decisions are stored, how knowledge is updated, and how different systems share context.

The companies that do this well will move differently. Their AI systems will not only answer questions. They will build continuity. Their agents will not only execute tasks. They will understand prior decisions. Their teams will not only generate content. They will compound institutional learning. This is the path from AI-augmented to AI-native.

A founder question I keep returning to is not just what we should build with AI, but what our organizations need to remember. I think the better starting question is simpler.

What does your organization need to remember?

Our brains are not powerful because they remember everything perfectly. They are powerful because they organize signals into patterns that help us act.

That is what I learned again while building Agent Memory Dump and SourceMind.

Memory is not a feature.

Memory is becoming infrastructure.

The core question on the table was heavy: How would Asia’s innovation, leadership, and cultural resilience shape a post-pandemic world, especially given the rapid acceleration of technology?

At the time, the conversation naturally gravitated toward digital infrastructure. Benjamin J. Butler, Founder of the Embassy of the Future, chaired the discussion with real insight. Klaus Neumann, Senior Vice President at SAP China, correctly pointed out that Asia’s success in managing the pandemic was largely due to the immense application of technology and a cultural willingness to embrace new digital tools. Lieutenant General Sudhir Sharma, Chairman of Mitkat Advisory Services in India, expressed strong optimism for a “V-shaped” recovery, driven by an accelerating spirit of entrepreneurship.

But Lieutenant General Sharma, drawing on his military and strategic background, also warned us. He pointed to looming geopolitical, ecological, and cyber risks, even assigning a 60% probability to a serious regional conflict within the next decade.

Looking back from April 2026, sitting in a world where autonomous AI agents are reshaping enterprise software while energy markets absorb the shockwaves of the ongoing conflict in the Middle East, his prediction feels uncomfortably prescient.

We are operating in a fundamentally different reality today. And yet, when I reflect on what I shared during that panel, one specific observation stands out as more relevant now than it was five years ago.

I argued that Asia’s growth is driven not just by consumerism, but by a unique “willingness of creativity.” In places like South Korea, a “less obedient” tactical mindset fosters “out of the box” thinking, contrasting sharply with more traditional manufacturing cultures.

More importantly, I emphasized a principle that I’ve learned the hard way, often through my own failures in scaling companies. It’s this: culture eats strategy for lunch.

In 2021, I applied that principle to the success of distributed workforces, arguing that future governance depends more on human-centric dialogue and trust than on technological infrastructure alone. Today, as we deploy multi-agent systems and grapple with global uncertainty across Asia and the Gulf, that principle is being tested under immense pressure.

The agentic reality of 2026

We are no longer just talking about AI as an assistant that drafts emails or summarizes meeting notes. We are building and deploying autonomous reasoning engines that understand context, plan workflows, connect to external tools, and execute actions across entire enterprise systems. Agentic AI is moving us from task automation to wholesale process reinvention.

But here is the reality I see on the ground, whether I’m working with engineering teams in Singapore, scaling operations in Seoul, or advising enterprises in Riyadh. I’ve made the mistake of thinking a new tech stack would solve operational issues, and I’ve paid the price for it. The bottleneck for AI adoption is rarely the technology itself. The bottleneck is the culture.

When you deploy an AI agent to manage your supply chain or handle complex financial underwriting, you are not just installing software. You are fundamentally changing how decisions are made and who (or what) makes them. If your organizational culture is rigid, top-down, and punishing of failure, your AI initiatives will fail. They will be stifled by a lack of trust and an inability to adapt.

The “willingness of creativity” I mentioned in 2021 is exactly what is required to build effective human-agent collaboration today. It requires a culture that is willing to experiment, willing to let go of legacy processes, and willing to trust autonomous systems while maintaining rigorous, human-centric oversight.

Navigating geopolitical uncertainty

This cultural adaptability is equally vital when navigating the current geopolitical landscape. The conflict in the Middle East has sent shockwaves through global energy markets and supply chains, testing the economic resilience of both Asia and the Gulf.

Yet, amidst this uncertainty, we see regions that are actively building resilience through innovation. The UAE and Singapore, for example, continue to attract investment and talent not just because of their geographic positioning, but because they foster environments that prioritize forward-looking governance and technological adoption.

During the Horasis panel, I raised concerns about data abuse and the security of sensitive information. In an era of geopolitical tension and autonomous agents, those concerns are magnified exponentially. Secure, sovereign AI infrastructure is no longer a luxury; it is a strategic necessity.

For Asia and the Middle East to strategically navigate these dual forces (the rise of agentic AI and regional instability), they must lean into their unique strengths.

1. Embrace the “less obedient” mindset: The regions that will thrive are those that encourage tactical creativity. When supply chains break down or energy prices spike, rigid adherence to the old playbook is a liability. We need operators who can think outside the box and leverage AI to build dynamic, self-healing systems.

2. Prioritize human-centric trust: As we delegate more authority to AI agents, the human element becomes more, not less, important. Trust (between cross-border teams, between citizens and governments, and between humans and machines) is the ultimate currency. You cannot code trust; you have to build it through dialogue and integrity.

3. Build sovereign resilience: The intersection of AI and geopolitics means that controlling your own technological destiny is critical. This means investing in local AI talent, securing critical data infrastructure, and building agentic systems that reflect regional values and priorities.

The enduring lesson

Building across Korea, the US, Singapore, Dubai, and Riyadh hasn’t given me a crystal ball, and I’ve certainly made my share of miscalculations trying to predict where markets are heading. But the mistakes I’ve made, and the teams I’ve had the privilege to lead, have taught me one enduring lesson: technology changes rapidly, but human nature does not.

In 2021, we were looking toward a post-pandemic future, hoping that digital tools would save us. In 2026, we have those tools in the form of incredibly powerful AI agents, but we are facing new, complex crises.

The lesson remains the same. You can have the most advanced multi-agent architecture in the world, and you can map out the perfect strategic response to market volatility. But if you do not have a culture built on trust, creativity, and resilience, it will fall apart under pressure.

Strategy is necessary. Technology is an accelerant. But at the end of the day, culture still eats strategy for lunch.

I have sat in enough boardrooms, product reviews, and operations calls to recognize a familiar pattern. The language changes faster than the system does.

A company says it is becoming AI-native. A team adds a model to an old workflow. A few internal demos go well. The roadmap gets rewritten in the new vocabulary. But underneath, most of the real decisions are still being made the old way.

That is why I keep coming back to a phrase I have heard in engineering and logistics for years: finding the shortest path.

On the surface, it sounds like an optimization problem. But after building across startups, enterprise systems, and operationally messy environments, I think it is really a strategic question. Not just how to get somewhere faster, but how to remove everything false between intention and reality.

That is what makes the current conversation around AI-native so interesting.

A lot of companies talk about becoming AI-native as if it were a branding milestone. A slide. A product feature. A line inserted into the CEO letter. But if we use the term seriously, it means something much more demanding. It means AI is not sitting on top of the business as a helper. It means the business itself has been redesigned so that AI is part of the operating substrate.

That is the difference between AI-washed, AI-augmented, and AI-native.

AI-washed is when an old product gets a new label. AI-augmented is when AI genuinely improves an existing workflow, but the workflow itself remains mostly human-designed and human-executed. AI-native is when the system, the data model, the decision logic, and even the human roles were built around AI from the beginning, or have been restructured deeply enough that AI is now on the critical path.

I made this mistake myself in the early days of building my first cross-border, end-to-end logistics platform. In 2010, as I built a system spanning order management through last-mile operations, I mistook better tools for deeper transformation. They are not the same thing. The clearest way I can describe it now is this: AI-native is not about having AI in the building. It is about letting AI change the floor plan.

The first analogy: the organizational shortest path

Many organizations say they want the shortest path to AI-native. What they usually mean is the shortest path to sounding AI-native.

That path is familiar. Add a chatbot to the website. Plug a model into a workflow. Ask teams to use copilots. Build a few demos. Rename the roadmap. Then speak as if the transformation has already happened.

But that is not the shortest path. That is the scenic route disguised as progress.

The real shortest path is more uncomfortable because it forces an organization to confront the truth of how decisions are actually made.

If every important output still waits for a human to review, approve, correct, route, and execute, then AI is not yet native. It may be useful. It may save time. It may even create real value. But it is still orbiting the core rather than sitting inside it.

This is where many leadership teams get trapped. They think AI maturity is about how many tools the company has adopted. In reality, the harder question is whether the company is willing to redesign operating authority, feedback loops, and role structure around what AI can now do.

That requires clarity across five dimensions. The first is architecture. Core workflows, data schemas, APIs, and latency assumptions have to be designed with AI inference in mind, not retrofitted later. The second is decision authority. AI cannot only advise; it has to close a meaningful share of decisions end to end within policy bounds. The third is data infrastructure. Operational data has to flow back into model improvement, not only into dashboards and monthly reporting. The fourth is organizational design. Human roles need to shift toward policy-setting, exception handling, and audit rather than routine execution. The fifth is moat. If AI were removed, the company should not merely slow down a little; it should lose a real part of its competitive advantage.

That last point matters more than most people admit.

If removing AI leaves you with basically the same business, just with more manual effort, then you are probably not AI-native. You are AI-augmented. There is nothing wrong with that. In fact, many good companies should honestly describe themselves that way today. But the distinction matters because strategy becomes distorted when vocabulary becomes dishonest.

A serious company should be able to answer a few objective questions.

Is AI on the critical path of major transactions? What percentage of decisions are actually closed by AI? Does more usage make the system better through a real data flywheel? Is headcount leverage improving because of AI, or are humans still scaling linearly with volume?

These are not marketing questions. They are operating questions.

And this is why I keep coming back to the idea of the shortest path. The shortest path is rarely the one with the best narrative. It is the one that removes ceremonial work. It is the one that asks, with some honesty, where the decision really happens.

The second analogy: the shortest path in logistics

This becomes much easier to understand when you stop talking in abstractions and move into operations.

Take a hypothetical last-mile delivery company in Singapore. Not a normal motorbike or van fleet. Imagine a company whose riders use the MRT as part of the delivery network for dense urban movement.

Now the phrase finding the shortest path becomes literal.

But in this operating model, the shortest path is not simply the shortest distance on a map.

It is the shortest executable path through a constrained system.

A rider starts at pickup, enters the MRT network, goes underground, loses GPS reliability, emerges at the destination station, exits onto the correct street, navigates the final walking path, accesses the building, and completes handoff. The route is shaped by train schedules, transfers, station geometry, exit placement, walking distance, parcel size, accessibility, and the fact that once the rider is underground, live rerouting becomes much harder.

That changes what an AI-native last-mile platform would have to be.

A normal AI-augmented platform might do something modest but helpful. It could suggest which station to use. It could summarize delivery notes. It could recommend an exit to the dispatcher. But the human operator would still coordinate the job, review the recommendation, message the rider, and absorb the failure when the route breaks.

An AI-native platform would look different.

Before a rider leaves the pickup point, the system would already have decided the full mission plan within policy limits: which MRT leg to take, which exit to use, which street the exit faces, which landmarks matter, whether lift access is available, whether the parcel is suitable for foot-carry, whether station congestion or exit closure changes the recommendation, and whether multiple drops can be batched into a single ride without breaking SLA.

The rider would not be waiting for human dispatch judgment as the default path. Human operators would step in only for exceptions: an inaccessible building, a parcel too bulky to carry, a station disruption, or a customer instruction that falls outside policy.

That is where the technology design and the operational design meet. In an AI-augmented version of the company, dispatch still belongs mostly to humans. The AI suggests a route, but a dispatcher approves it. Transit planning remains fairly static. Exit intelligence is limited to basic station or coordinate lookup. Failed deliveries are reviewed manually, and the operations team still manages most delivery decisions directly.

In an AI-native version, that same flow changes character. The AI assigns the route and the exit autonomously within policy. Pre-departure planning is optimized around train timings, transfer risk, and walkability. Exit intelligence becomes much richer, incorporating street-facing direction, nearby landmarks, lift access, and real-time overrides. Delivery outcomes continuously improve routing logic and operating policy. And the operations team shifts away from managing every decision toward managing policies, exceptions, and system performance.

That is the real threshold.

If the AI only helps a dispatcher work faster, the company is more intelligent than before, but not yet AI-native. If the AI becomes the dispatch layer, the planning layer, and the learning layer, with humans moving into supervisory roles, then the claim becomes much more credible.

Where MCP fits, and where it does not

This is also why I have been thinking about one of my recent open-source projects, the SG MRT Exits MCP Server.

The project is useful because it exposes structured exit-level information to AI agents. Instead of leaving the model to reason from a raw map pin, the system can answer questions like which exit is nearest, what the exit label is, what street it faces, and what landmarks are nearby. For any agent trying to reason about dense urban movement in Singapore, that is a meaningful improvement in context quality.

But building a good MCP server, even a full-fledged one with multiple tools, does not automatically make the surrounding business AI-native.

It makes the AI better informed.

That is important, but it is not the same thing.

An MCP server is a structured interface between an agent and the world. It is a tool layer. Whether the broader system is AI-native depends on what sits above and below that layer.

Above it, you need an AI agent or decision engine that actually uses that context to make consequential decisions on the critical path.

Below it, you need feedback, proprietary data accumulation, operational integration, and organizational redesign so the outputs are not just interesting answers but executed actions.

In other words, MCP is necessary in many AI systems, but it is not sufficient for AI-native status.

A company could build excellent MCP servers and still remain AI-augmented if humans continue to make the real decisions. On the other hand, the same MCP foundation can become part of an AI-native architecture if it feeds an autonomous decision loop with measurable closure, learning, and leverage.

This is the honest way I would describe a startup using something like the SG MRT Exits MCP Server today: not fully AI-native yet, but meaningfully on the path.

Why? Because exposing tools to agents is an architectural choice that shows AI-native thinking. It treats AI as a first-class consumer of structured operational context. That matters. But if the agent still only recommends while people still decide, coordinate, and recover manually, then the business has not crossed the line.

What would make the MRT delivery company truly AI-native

To push the hypothetical MRT-based last-mile company across that threshold, several things would need to happen at the same time.

First, it would need loop closure. The agent must assign riders, choose exit strategies, and issue executable plans by default, with exceptions routed to humans rather than the reverse.

Second, it would need proprietary context layers beyond public data. Static MRT exit geometry is useful, but not enough. The company would need its own operational knowledge about which exits are faster in practice, which ones are frequently obstructed, which buildings are easiest to approach from which side, which exits are unsuitable for heavy parcels, and how station-to-door walking times differ by time of day.

Third, it would need a real data flywheel. If riders ignore a recommended exit because construction made it unusable, that signal should flow back into the system. If one route consistently misses SLA at 8:30 a.m. but performs well at 11:00 a.m., the platform should learn from that. If one building’s loading access is always delayed without a call-ahead, the planning logic should absorb that too.

Fourth, it would need organizational redesign. The question would no longer be, “How do we help dispatchers make better decisions?” It would become, “How do we define policy boundaries, exception protocols, and model performance metrics so dispatch scales without adding linear headcount?”

That is the difference between automation inside the workflow and redesign of the workflow itself.

And this is where I think a lot of AI conversations still miss the point. People often ask what model to use, what tool to integrate, or what agent framework to adopt. Those are valid questions, but they are downstream questions.

The upstream question is whether you are redesigning the company so that AI can take the shortest path from information to action.

The strategic test

When founders or executives say they want to become AI-native, I think there is one question they should ask themselves before anything else.

If AI were allowed to operate at full strength inside our business, what decisions would it actually own, what feedback would make it better, and which parts of our current organization would need to be redesigned because of that?

That question is strategic because it forces honesty about architecture, authority, data, org structure, and moat all at once.

And when building an AI-native product or solution, the domain-specific version of the same question becomes even sharper.

What is the shortest executable path from raw context to successful action in this domain, and have we designed both the technology stack and the operating model so AI can own that path by default, with humans handling only policy and exceptions?

For an MRT-based last-mile platform, that means asking whether the system can move from pickup to station choice to exit choice to handoff completion as one coherent AI-led chain, rather than as a collection of disconnected recommendations. For other industries, the path will look different, but the principle stays the same.

That, to me, is what AI-native actually means.

Not AI everywhere.

Not AI as branding.

Not AI as a feature added to old assumptions.

But a system, and an organization, rebuilt around the shortest path between knowing and doing.

Not just any trip. A Seoul-to-Busan run on May 15th with a friend visiting from Saudi Arabia, someone I care about getting this right for. That means halal-friendly dining. That means traditional Korean food, not tourist food. That means a restaurant that actually understands what a Muslim guest needs, and does it without compromise.

I gave the agent a single instruction. Something like: Plan the day trip, find the best traditional Hansik restaurant appropriate for my Saudi Arabian friend, prepare a full document with restaurant details, photos, hours, and a Google Maps link.

Ten minutes later, I had it all. A clean itinerary that fit my train schedule. A 43rd-floor restaurant overlooking the city with a dedicated halal menu. A scenic hillside walk behind Busan Station with a monorail ride and panoramic views of the port. A document I could hand to my guest and feel proud of.

Distribution is the game. It always has been.

I’ve been thinking about this for a while, and I’ll say it plainly: I believe that in the years ahead, and arguably right now, what separates organizations is not the quality of their product. It is their brand, their distribution, and the community they’ve built around.

This is true for a solo entrepreneur. It is true for a startup. It is true for an agency. And it is especially true in the technology industry, where product engineering, product marketing, and product sales are becoming more commoditized by the month.

The rise of AI agents is accelerating this. When any motivated founder with a clear head and the right tools can build a capable product in weeks, the product itself is no longer your moat. What you’ve built around it, the trust, the reach, the relationships, the information architecture that makes it actually useful, that is the moat.

I’ve understood this intuitively for years. But it wasn’t always obvious what that looked like in practice.

Back in May 2018, after about a year of living in Singapore, I kept running into the same quiet frustration. Singapore’s hawker centres, these incredible community food halls that are genuinely part of the national identity, had a government dataset behind them. Rich, structured, useful information. But accessing it required wading through bureaucratic formats that weren’t designed for developers, and certainly not for anyone who wanted to build consumer-facing experiences on top of them.

So I built a fully managed API. Clean, structured, searchable access to Singapore’s hawker centre dataset, published on RapidAPI. It wasn’t a product in the traditional sense. It wasn’t meant to be a business. It was a distribution layer. A bridge between data that existed and the experiences that could exist, if someone just made it accessible.

That’s what I was solving. Not a product problem. A protocol problem.

The gap nobody keeps score on

I came across a TripAdvisor report that named Seoul the top destination for solo travelers for 2025. Knowing what I know about Seoul, this didn’t surprise me. But it did make me think harder.

The travel industry has been reshaped. Experiences have become the product. Personalization isn’t a feature, it is the expectation. Skift’s research makes this clear: personalization runs through virtually every major travel industry trend right now, from loyalty to AI adoption to competitive differentiation. Travelers don’t want to be routed through a generic experience anymore. They want something that sees them.

That creates enormous pressure for operators in the travel space to move faster and know more. And it creates an interesting opening for builders.

Because here’s the thing that doesn’t get talked about enough: the data and information that would enable great personalized experiences often exists. It exists in government databases, in tourism boards’ content systems, in local business registries, in cultural heritage records. The problem isn’t that the information isn’t there. The problem is the shape it’s in, and the protocols through which it can be reached.

This is why I built and open-sourced the VisitKorea MCP server.

Korea Tourism Organization has a rich API. But making it genuinely useful for AI agents, for the kind of orchestrated, multi-step, context-aware workflows that can actually power meaningful personalized experiences, requires bridging a gap. The MCP (Model Context Protocol) server I built wraps Korea’s tourism data in a format that AI agents can natively understand, query, and act on. It’s published on GitHub under MIT license. Free for personal use, free for commercial use. Anyone building on it, take it.

And when I connected it to an AI agent like Anthropic Claude or Manus AI, paired with a skill built to manage my calendar and plan travel workflows, ten minutes became enough to produce something I’d feel proud handing to a guest.

The infrastructure nobody’s celebrating

Here’s where I’ll say something that probably won’t trend.

Data centers are getting all the headlines. Energy infrastructure for AI compute is a legitimate and important conversation. I understand why it’s dominating the room. But there is another layer of infrastructure that I believe is just as important and far less resourced: the work of making existing data usable.

There is an enormous amount of information in the world, structured, semi-structured, unstructured, sitting in systems that were never designed to talk to AI agents. Government data portals. Tourism content management systems. Healthcare records. Logistics databases. Financial registries. This information is real. It is often accurate. It is often valuable. But it exists in formats, behind protocols, and within technical architectures that make it invisible to the generation of tools being built right now.

LLMs will not solve this on their own. Even the best large language models, when asked about specific and accurate local information, require a retrieval layer. That’s why RAG, retrieval-augmented generation, is so widely adopted today. The model does not know your local hawker centre. It does not know Korea’s regional tourism data. It does not know the halal certification status of a restaurant on the 43rd floor of a hotel in Busan. Not reliably. Not in the shape you need.

Someone has to build the bridge.

What I believe about software’s future

I still believe it’s meaningful to build software. I want to be clear about that. But the terminal value that software once commanded, the idea that a well-engineered product, by virtue of being well-engineered, would naturally compound into a durable business, I think that assumption needs to be updated.

The cost to build is falling. Fast. The expectation for what software should do is rising. Just as fast. That’s not a pessimistic statement. It’s actually an invitation. The ceiling is higher. But the floor has moved too. You can’t compete on “we built a thing” anymore. You compete on brand, distribution, community, and whether the information that powers your experience is accurate, contextual, and genuinely useful.

What I built with the Hawker API in 2018 and the VisitKorea MCP in 2026 is the same instinct applied twice, across different times and technologies. The instinct is this: if the data exists but the access doesn’t, build the access layer. That’s distribution. That’s infrastructure. That’s how you become useful in a world where models are powerful but only as smart as the information they can reach.

What doesn’t exist, still doesn’t. Until someone decides to build it.

Most people have more story than they know what to do with.

A week of meetings, decisions, small wins, quiet frustrations, moments that meant something. And almost none of it gets told. Not because it isn’t worth telling, but because the gap between living something and shaping it into a story is wider than most tools have ever tried to close.

That gap has been bothering me for a while.

The tools got powerful. The problem didn’t go away.

There’s no shortage of AI tools for expression right now. Text generators, image makers, video creators. The output quality has never been higher. And yet most of what gets produced still feels generic, because the tools are only as specific as what you put in. They’re powerful, but they still put the full burden of storytelling back on the user.

You have to know what to say. How to frame it. What to prompt. And most people’s real stories don’t arrive pre-packaged like that. They’re fragmented. Unresolved. Half-remembered. The raw material is there, but the tools keep asking you to do the hardest part yourself before they’ll help you with anything.

That’s not a content quality problem. It’s a starting point problem. And the same gap shows up in how we build.

For founders building with AI, the version of this problem is just more visible.

Vibe coding is having a moment. But a lot of what I see underneath is UI-driven development dressed up in new language. Describe the interface, react to what comes back, tweak, repeat. No narrative spine underneath any of it. The interface was never the hard part, and agents don’t fix that. They just move faster.

If you couldn’t pitch your idea clearly in five minutes, covering who it’s for, what it must never do, and what success actually looks like, you probably aren’t ready to hand it to an agent either. Garbage in, garbage out. It just moves faster now.

This is where Memtoon.com came from. Connect your Google Calendar, and your real week becomes a webtoon-style comic strip, written and illustrated by AI, with no prompting required on your end. Your events are the raw material. The story shapes itself.

Building it required me to practice what I’ve been describing. I had to tell the agent a complete story before a single line of code: who the user is, what the product must never do, what privacy-first actually means as a constraint rather than a claim. Calendar data fetched, used, discarded. Selfies deleted within seconds across every code path. Not policy language. Architecture.

And because I believe a good story is built through dialogue, not instruction, I asked the agent to maintain a living document recording every design decision it made beyond my direction, and every instance it chose a different approach, along with its rationale. Not a changelog. A record of its reasoning. So I could ask: why did you choose this? what were you protecting? That’s not a workflow preference. It’s a different belief about what building actually is.

Here’s an ask I’m leaving with you.

Memtoon is live at memtoon.com. There’s an explainer video that walks through how it works. Check it out and tell me what you actually think.

But the question underneath all of this isn’t really about Memtoon. It’s about where your story is living right now, and what it would take for it to finally get told.

The story was always the product. It just took AI to make that undeniable.

A few days ago, I gave my personal assistant agent a straightforward instruction:

“Find a 1 hour workout time slot at a Gym Pod location for tomorrow that fits my schedule. Prioritize gym locations accessible by MRT. I prefer not to take a Grab taxi.”

That’s it. Single instruction. No follow-up. No clarification needed.

Now, if I had asked my agent something simpler, like “Summarize my calendar for tomorrow” or “Add a meeting at 3pm,” I’d honestly tell you: just open the calendar app. It would be faster. It would be cheaper. You don’t need an AI agent to read your own schedule back to you.

But this wasn’t that kind of request.

To fulfill what I asked, my agent had to do something a calendar app never could. It had to pull my calendar events for the next day, identify the fixed commitments and their locations, calculate the open windows between them, look up Gym Pod locations across Singapore, filter for ones accessible by MRT from where I’d already be during those open windows, cross-reference travel times, and find a slot where a one-hour workout, plus transit, actually fit without blowing up the rest of my day.

That’s not a prompt response. That’s a workflow.

And the difference between those two things is exactly what this post is about.

The prompt trap

There’s a pattern I see constantly. Someone discovers ChatGPT or Claude, gets excited, and starts collecting prompts. They download prompt packs from LinkedIn. They screenshot “Top 10 Prompts for Productivity.” They paste in a paragraph and hope for magic.

I get it. The first time an LLM writes a decent email for you or summarizes a document in three seconds, it feels like the future just arrived at your desk. But here’s the thing: that’s inference. You gave the model an input, it gave you an output. That’s powerful, sure. But it’s also just the surface.

What most people don’t realize is that the real unlock isn’t in the quality of a single prompt. It’s in how you structure the knowledge, context, and workflow logic that sits behind the prompt. It’s in what the AI industry calls skills.

And skills are fundamentally different from prompts.

What a skill actually is

On platforms like Anthropic’s Claude and Manus AI, a skill is a structured, reusable instruction set that tells an agent how to think about a domain, not just how to respond to one question. Think of it as the difference between handing someone a script for one phone call versus training them for the job.

A prompt says: “Write me a professional email declining this meeting.”

A skill says: “You are a personal assistant. You have access to my calendar, my contact list, and my location history. You understand my scheduling preferences, my transit constraints, and my priority framework. When I ask you to handle scheduling, you don’t just look at open time. You consider travel time, energy management, the nature of adjacent commitments, and my stated preferences about transportation. You confirm before booking. You flag conflicts. You learn from corrections.”

See the difference?

A skill encodes domain knowledge, behavioral rules, workflow sequences, tool access permissions, and contextual understanding into a persistent framework that the agent can draw on every time it’s activated. It doesn’t disappear after one exchange. It compounds.

The technical structure varies by platform, but the principle is consistent. On Claude, skills are bundled as instruction sets with references, tool configurations, and behavioral directives. On Manus AI, the architecture is similar: skills carry identity context, domain expertise, decision-making logic, and integration hooks. In both cases, the skill acts as an operating manual for the agent within a specific domain.

This is why my personal assistant agent could handle the gym request without a ten-paragraph prompt from me. The skill already carried the context: who I am, where I live, how I move around Singapore, what tools it has access to (calendar, maps, location data), and what “fits my schedule” actually means in practice. I didn’t need to explain any of that in the moment. The skill had already been built.

The first takeaway: Task design is the real skill

Here’s what I want people to understand, especially founders and operators: the magic isn’t in the model. It’s in how you define and distribute tasks so that an agent can execute through a genuine agentic workflow.

When I asked my agent to find a gym slot, I wasn’t asking it to think for me. I was asking it to act for me, to chain together a sequence of subtasks that would have taken me fifteen to twenty minutes of app-switching, map-checking, and calendar-squinting. The agent understood the fixed variables (my schedule, event locations), applied the constraints I care about (MRT access, no Grab), and worked through the problem step by step.

If you only use AI to generate text responses (summarize, rephrase, draft) you’re using about ten percent of what’s available to you right now. That’s not a criticism. Inference is valuable. But it’s not the same as transforming your workflow into an agentic environment where the AI doesn’t just respond but operates.

The shift is this: stop thinking of AI as a tool you query. Start thinking of it as a teammate you brief.

And like any good teammate, the quality of the briefing determines the quality of the output. But unlike a prompt you type fresh every time, a skill means you only have to brief once. After that, the agent carries the playbook.

From personal to enterprise: The Odoo story

Let me take this from personal productivity into business operations, because that’s where the implications get serious.

In my previous post, I briefly mentioned that my agents have Odoo expert skills. As an official Odoo certified consultant and Learning Partner, I’ve spent enough time inside the platform to know both its power and its complexity. Let me unpack what that combination of domain experience and agent skills actually means, and what it made possible.

Recently, I developed a custom MCP (Model Context Protocol) server that allows my agents to connect directly with Odoo ERP systems. For those unfamiliar, Odoo is a comprehensive open-source ERP platform that handles everything from CRM and accounting to inventory, HR, project management, and more. MCP is the protocol layer that lets AI agents communicate with external tools and data sources in a structured way. Think of it as the plumbing that connects the agent’s brain to the systems it needs to operate in.

Building that MCP server took me two hours. And I want to be specific about what “building an MCP server” actually means, because the scope matters.

The core development alone included writing a full Odoo XML-RPC client with authentication, session handling, and error mapping. It meant defining 16 distinct tool definitions, each with proper input schemas and validation, so the agent knows exactly what operations are available and how to call them correctly. On top of that: a JSON-RPC 2.0 handler covering the full protocol lifecycle (initialize, tools/list, tools/call), a FastAPI server supporting both Streamable HTTP and SSE transports, a STDIO transport with an entry point that handles transport switching, and config/environment loading to make the whole thing portable across different Odoo instances.

Then there’s testing and debugging, deployment and infrastructure, and documentation. In total, this is not a weekend hack or a quick script. A senior developer, someone comfortable with XML-RPC, JSON-RPC, FastAPI, and the MCP specification, would realistically need 32 to 48 hours to ship all of that to production quality. That’s a full workweek, minimum.

I did it in two hours. Not because I’m faster than a senior developer. Because my agent, equipped with the right skills and the right context about what I was building, handled the heavy lifting while I focused on the architectural decisions and the parts that required my judgment.

Two hours to design, develop, test, and deploy a fully functional bridge between my AI agents and any Odoo environment. That server can now handle any task that Odoo’s APIs expose: creating records, reading data, updating workflows, triggering automations. The full scope.

But the MCP server alone isn’t what made the next part possible. What made it possible was the skill layer sitting on top.

My agents carry Odoo expert skills, built from official Odoo documentation, functional references, and workflow logic that I’ve programmed based on years of working with ERP systems. The skill doesn’t just know what Odoo is. It understands how Odoo modules relate to each other, how data flows between apps, what a properly configured sales pipeline looks like, how inventory valuation affects accounting entries, and what steps are required to set up a functional instance from scratch.

So when I decided to put together a demo Odoo environment for a football academy (a soccer training organization with players, coaches, schedules, memberships, and equipment) I didn’t sit down and click through Odoo’s interface for three days. I gave my agent the business context and said, essentially: “Here’s what this organization does. Set it up.”

The agent installed the appropriate Odoo apps and modules. It created the organizational structure. It populated the system with context-relevant, branded demo data: player profiles, coaching staff, training schedules, membership tiers, inventory for equipment and kits. The works. The entire setup, from a blank Odoo instance to a fully populated, functional demo environment, took two hours.

There was one hiccup. Midway through, the agent created some duplicate player records. But here’s the thing: because the skill included self-correction logic (something I built into the workflow instructions from the beginning), the agent caught the error, identified the duplicates, cleaned them up, and continued. No intervention from me. No panicked Slack message. It just handled it.

Now, let me put that in perspective. I’ve worked with ERP systems across my career: as a certified Odoo consultant, as an engineering leader integrating enterprise platforms for clients like UPS, Samsung, and Hyundai, and as a founder building products on top of complex data architectures. I know what this kind of work costs.

A human ERP consultant, someone with functional certification and pre-sales or technical consulting experience, would need a minimum of 24 to 32 dedicated hours to achieve the same result. That’s three to four full workdays in theory. In practice, factoring in context-switching, client communication, revision cycles, and the inevitable “let me check the documentation” moments, you’re looking at more. Probably a full week or more of billable time.

My agent did it in two hours. Not because the agent is smarter than an experienced consultant. But because the agent had the right skill, the right tool access, and the right workflow architecture to execute without friction.

The architecture that makes this work

Let me break down the stack so this isn’t abstract.

At the base, you have the AI model. Claude, GPT, or whatever foundation model you’re working with. This is the reasoning engine. It’s powerful, but on its own, it’s like having a brilliant analyst locked in a room with no phone, no computer, and no files.

Next, you have tools and integrations: MCP servers, API connections, browser access, calendar hooks, database connectors. These are the hands and eyes. They let the agent interact with the real world: read your calendar, query a database, navigate a web interface, create records in an ERP.

Then you have skills: the structured instruction sets that tell the agent how to operate within a domain. This is the training, the playbook, the institutional knowledge. A skill carries the why and how, not just the what.

And finally, you have context: the specific information about your situation, your business, your preferences, your constraints. Context is what makes the same skill produce different (and correct) outputs for different users or scenarios.

When all four layers work together (model, tools, skills, context) you get genuine agentic behavior. The agent doesn’t just answer questions. It plans, executes, self-corrects, and delivers outcomes.

Strip away any one of those layers, and the experience degrades. A model without tools can only talk. Tools without skills produce random actions. Skills without context produce generic outputs. And context without a model is just a database.

This is why downloading a prompt from someone’s LinkedIn post and pasting it into ChatGPT will never replicate what a properly skilled agent can do. The prompt is one layer. The system needs four.

The mindset shift

I want to close with something that I think matters more than any technical architecture.

Agentic workflows are powerful when you’ve done the homework. When you’ve assessed your existing workflows, defined your tasks clearly, established what “done” looks like, and understood where an agent can genuinely add leverage versus where it’s just adding complexity.

But asking an agent to save you from what you don’t know? That’s not leveraging AI. That’s outsourcing your thinking, and no model, no matter how good, will consistently save you from that.

I believe the better starting point is this: skill up. Be open to learning. Be willing to pivot from the way you’ve always done things. That’s not easy. I understand the anxiety around AI replacing jobs, disrupting industries, changing the rules of the game mid-season. But fear-driven inaction is a worse strategy than imperfect experimentation.

If you’re a founder, an operator, a builder, an aspiring entrepreneur: start by understanding your own workflows deeply enough to teach them to an agent. That exercise alone will make you better at your job, even before the agent does anything. And when you do hand it off, you’ll be handing off a well-defined play, not a vague hope.

Perhaps the quality of a response generated by Claude versus ChatGPT on pure inference shouldn’t be your true north star. The real question isn’t which model gives a better answer to a single prompt. The real question is: which system, with model, tools, skills, and context working together, can reliably execute the workflows that actually move your work forward?

That’s where the game is heading. And the players who understand the playbook will have a serious advantage.

That is, more or less, what I did when I started building my AI team.

I am not talking about a team of full-time employees. I am talking about something new. A set of collaborators that do not sleep, do not negotiate salary, and do not need to be managed in the traditional sense. They need to be instructed. And the quality of that instruction determines everything.

This post is about that team. What it looks like. How it was built. Why it works. And honestly, what it still cannot do, because I have no interest in making this sound shinier than it is.

The company has changed. Not all companies. But enough.

Let me be precise here, because I think the sweeping declarations about AI replacing everything are both unhelpful and slightly dishonest. Not every industry is being reshaped at the same velocity. A restaurant, a law firm defending criminal clients, a physiotherapy clinic. These still depend on physical presence, human judgment, and trusted relationships in ways that no AI product is yet fully replacing.

But for founders, startup operators, product builders, and independent professionals working in knowledge, content, sales, systems, and digital services? The ground is shifting. Quickly. And the shift is not primarily about automation. It is about leverage.

The old model said: hire people who have the skills you lack. The new model says: build systems that extend your capability, and hire people who can operate and improve those systems alongside you. The new model does not eliminate people. It raises the bar for what kind of people and what kind of contribution is actually necessary.

In a startup with five people, every single person used to be responsible for a distinct function. Now, one person with well-structured AI workflows can cover the surface area that once required three. That is not a reason to lay people off. It is a reason to think very differently about what a role means, what a company needs, and who belongs on a founding team.

I have been thinking about this for longer than I have been willing to say publicly. And I have been quietly building. This post is me finally talking about what that building actually looks like.

Before I go deep on the tools and the technical architecture, let me introduce you to the team the way I would introduce a new hire cohort to a company. Not by job title. By function and contribution.

Across two environments, Manus AI and Claude AI, I have built a set of AI skills. Think of a skill not as a chatbot, but as a trained specialist. Each one has a defined mandate, a set of operating instructions, reference materials, and a specific workflow for how it does its job. Each one is built to do one thing well, repeatedly, without drifting.

Here is the roster at a glance:

• Cofounder: My stress-testing partner. Challenges my ideas, pokes holes in my logic, rewrites weak problem statements, and helps me sharpen pitches and product hypotheses.

• Personal Assistant: My chief of staff. Manages my profile, schedule, tasks, budget checks, and multi-skill orchestration.

• LinkedIn Navigator: My lead generation and prospecting specialist. Runs ICP development, LinkedIn search strategy, buyer persona profiling, and SDR/BDR outreach copy.

• Account Executive: My full-stack B2B revenue operator. Covers the entire sales cycle from cold outreach to closing, including Apollo.io workflows, MEDDPICC qualification, pipeline management, and founder-led sales.

• Global HR & TA Specialist: My talent and people advisor. Supports resume evaluation, hiring strategy, talent acquisition frameworks, and job market guidance across global markets.

• Gumroad Expert: My digital product and creator economy operator. Handles Gumroad setup, product positioning, pricing strategy, listing copy, and creator storefront growth.

• Nas.io Community Manager: My community management operator for NAS.io communities. Manages engagement, content, and member support for that specific audience.

• Social Media Manager: My content distribution operator. Plans, scripts, formats, and optimises content for social media channel, particularly short-form and platform-native formats.

• Blog-by-Jae: My editorial voice. Writes long-form blog posts in my exact voice, tone, and storytelling structure. This post was written with its guidance.

• Solution Architect: My technical design partner. Turns product ideas, system requirements, and app briefs into architecture diagrams, technical specs, and LLM-ready development instructions.

• Odoo Expert: My ERP and operations specialist. Handles Odoo configuration, module selection, workflow design, and implementation guidance for business operations.

• Breach Lookup: My security intelligence specialist. Handles credential breach monitoring and lookups to support data protection hygiene.

Twelve specialists. All available simultaneously. None of them require onboarding, performance reviews, or catering at the all-hands. What they do require, and this is the part that most people underestimate, is quality instruction.

The simplest starting point: ChatGPT projects

Before we get into the more sophisticated infrastructure, let me start where most people start, and where I still operate for many things. ChatGPT Projects.

If you are new to this, here is the clearest analogy I can give you: a ChatGPT Project is like a dedicated notebook for a specific area of your work, with a standing briefing note taped to the inside cover. Every conversation that happens inside that notebook reads the briefing note first. So when you open the notebook and ask a question, the AI already knows who it is supposed to be and what context it is working inside.

That briefing note is called a system prompt. And it is one of the most underrated tools in practical AI usage today.

What is a system prompt, and why does it matter?

A system prompt is a set of instructions given to an AI before the conversation begins. It defines the role, the tone, the scope, the constraints, and the operating context. It is not a question. It is a mandate.

Think of it like a job description, an onboarding document, and a brand voice guide rolled into one paragraph. When it is written well, the AI behaves like a trained specialist. When it is vague or absent, the AI behaves like a talented generalist who is guessing what you need.

The difference between a useful AI interaction and a frustrating one is almost always the quality of the setup, not the capability of the model. Most people blame the model. The real issue is the instruction.

The beauty of GPT projects is simplicity. No code. No integration. Just a well-written system prompt and a consistent workspace. For quick advisory loops, drafting, and thinking out loud with context. Projects are fast and effective.

But they have a ceiling. And that ceiling is where Custom GPTs come in.

Custom GPTs: When you need more than a system prompt

If ChatGPT Projects are a notebook with a standing briefing note, then Custom GPTs are a specialist who has been trained, given reference documents, handed a set of tools, and told exactly how to handle specific types of requests.

The technical distinction matters, so let me be direct about it:

A ChatGPT Project is a persistent chat context with global instructions. A Custom GPT is a purpose-built AI application with grounded knowledge, specific capabilities, and optional third-party integrations.

A Custom GPT can be given uploaded documents that it references when answering, so it is not just guessing from general training data, it is drawing from your specific materials. It can be connected to external APIs. It has a configured conversation style, a defined scope, and a persona that is consistent across all users who interact with it. It is, in essence, a lightweight product, not just a chat thread.

The tradeoff: Custom GPTs take more time to build well, and their quality depends heavily on the design of their knowledge base and instructions. They are also more appropriate for repeatable, structured use cases than for open-ended advisory conversations.

Now here is the honest distinction between using a Custom GPT and using an agent for content generation: a Custom GPT gives you grounded, structured, reference-informed responses in a consistent format. It is excellent for repeatable deliverables; such as a resume review, a translated phrase, a trip itinerary, a technical spec. An agent, by contrast, can take multi-step autonomous action. It can search, retrieve, synthesise, and produce across a workflow, not just in a single response. They are different tools for different jobs. The mistake is treating them as interchangeable.

Agent skills on Manus and Claude

Now we get to the part of the stack that I find genuinely exciting — and that I also think is the most misunderstood.

Custom GPTs and ChatGPT Projects are conversational tools. They are excellent. But they are fundamentally reactive. You ask; they respond. The work of sequencing, deciding what to do next, navigating across systems, and executing a multi-step workflow that still falls to you.

Agent skills are different. A well-designed skill is not just a set of response instructions. It is an operating procedure. It describes the objective, the workflow steps, the inputs and outputs, the decision logic, the tools to use, and the acceptance criteria for a completed task. When you give a capable AI agent a well-written skill, you are not starting a conversation. You are delegating a workstream.

I currently run skills across two environments: Manus AI and Claude AI. Both have different strengths. Manus is my primary environment for agentic execution; browser automation, multi-step task completion, long-horizon workflows. Claude is my primary environment for deep reasoning, writing, and structured document work. The skills I build for each are tuned to those strengths.

What makes a skill different from a system prompt?

Think of a system prompt as a job description. It tells the AI who it is and how to behave. A skill is more like a standard operating procedure. It tells the AI what to do, in what order, with what tools, and how to verify that the work is done correctly. The best skills I have built include: the purpose and scope of the role, the specific workflow steps broken into phases, the inputs required and outputs expected, the tools and resources available, edge cases and error handling, and the quality bar for the final deliverable.

The difference in output quality between a well-structured skill and a loosely written one is not subtle. It is the difference between a reliable team member and someone who is talented but needs constant supervision.

Friction, limits, and what still needs humans

I would be doing you a disservice if I ended this post without being direct about where things break down. Because they do break down. And I think the people who pretend otherwise are selling something.

Browser automation is the one obvious gap right now. Agentic AI tools are capable of extraordinary things when working inside well-structured data environments; documents, APIs, databases, structured inputs. But the moment you ask an agent to navigate a real web interface, such as to scroll a page, handle a popup, interact with a dynamic JavaScript-rendered UI… the reliability drops noticeably. It works. Sometimes it works well. But it is not at the level where I can set it and forget it for browser-dependent workflows without expecting to check in.

This is not a criticism of any single product. It is a current state of the technology. And when it is resolved, when browser automation becomes as reliable as document processing, the agentic experience will take a significant leap. The wings are almost there. The flight is still a little wobbly.

Here is where I want to be honest about something that is harder to say cleanly.

Human contributors still matter. They matter a lot. But the bar for what constitutes real contribution has risen sharply, and I think pretending otherwise is a disservice to everyone involved.

The people I most want to work with now are not people who have impressive titles or long CVs. They are people who know their own knowledge precisely, who can tell me, specifically, what they are good at, what their process looks like, what outcomes they have produced, and where their thinking breaks down. That level of self-knowledge is rare. And it is now more valuable than general capability, because general capability is increasingly available from the tools.

What I want to avoid at all costs (in human collaborators, and in AI systems) is vagueness. The person who cannot articulate the objective. The person who cannot walk me through their process. The person who responds to ‘how would you approach this?’ with a list of soft skills and good intentions. Vagueness used to be acceptable because experience was hard to transfer. Now, vagueness is a liability. Because the ability to transfer knowledge, to articulate it clearly enough that a system, a junior, or an AI can act on it, is exactly what determines how much leverage you can create.

I am not trying to be harsh about this. I genuinely want to work with other founders and operators who have done the work of understanding themselves. Who have their own processes, their own frameworks, their own hard-won convictions about how things should be done. Even if those frameworks are unconventional. Even if they have not been widely validated. The specificity is the value. A person with a clear, structured, idiosyncratic view of how to do their job is infinitely more useful in an AI-augmented environment than a person with a vague but widely acceptable one.

Because structured, specific knowledge and articulated logically, with clear inputs, expected outputs, potential failure modes, and known constraints, is exactly what gets transformed into a working skill. And a working skill, given to a capable agent, becomes leverage.

The people who thrive in this new environment will not be the ones who were the most generally capable. They will be the ones who were the most clearly self-aware about what they actually know and how they actually work.

I started this post by talking about a baseball manager walking to the mound. The manager does not throw the pitches. The manager creates the conditions under which the pitcher can throw them well.

The company I am building does not look like the companies that came before it. It is leaner by design. It is more leveraged by intention. It requires me to be more self-aware, more structured, and more articulate about how I work than any previous stage of my career has demanded.

I would not have it any other way.

If any of this resonates, and if you are building something similar, thinking about how to structure your own AI stack, or just trying to figure out where the real leverage is in all of this… I would genuinely like to hear from you. The work is more interesting when the thinking is shared.

South Korea versus the Dominican Republic in the WBC quarterfinals. The gap wasn’t just on the scoreboard, it was in everything… the at-bats, the pitch selection, the defensive positioning. As someone who’s spent years looking at this game through data and a SABR analytics specialist, I didn’t need the final out to tell me what the numbers already had.

But losing a game I care about does one useful thing. It makes me ask questions. Which Korean hitters had been struggling before this tournament? Were there signs in the KBO numbers? What patterns were hiding in the data that nobody surfaced in time?

A few days ago, I was catching up with a close friend who’s a rising FIFA-licensed agent. We were talking about how sports organizations handle player data, and he said something offhand that I haven’t been able to shake.

He wasn’t complaining. He was just observing. But what he was really describing is a challenge I’ve seen inside nearly every organization I’ve worked with, and a long list of startups across Asia, the Middle East, and North America. The pattern is identical whether you’re calling a baseball game or running a quarterly business review.

And what started as a personal baseball project accidentally became my analogy for explaining this to organizations.

So here’s what I actually built, because the experience is the lesson.

Approach one: just ask ChatGPT. ChatGPT and most LLMs do have web access these days, but current KBO statistics are not exactly their strong suit. The result was a confident-sounding answer built on thin air. This is what LLMs do when they lack grounding in specific, real data: they estimate, extrapolate, and occasionally just make things up while maintaining excellent posture.

Previously, I also built a Baseball Data Analyst custom GPT for the purpose of having a conversational experience with specialized context, voice interface, baseball analytics framing. Genuinely useful for general reasoning, historical context, analytical frameworks. But for specific private statistics? A well-configured GPT without grounded data is a confident intern who’s never actually seen your files.

Approach two: fine-tune a model on the data. What if I just trained the model on KBO player statistics directly?

I built a fine-tuning pipeline in Google Colab, because most of us don’t have enterprise GPUs sitting around. The process is more accessible than it sounds. Take a base model like Llama 3.1 8B from Hugging Face, apply LoRA (a lightweight technique that adjusts only a small fraction of model parameters, keeping compute costs reasonable), feed it your dataset, and train it on a free T4 GPU in Colab.

The part most tutorials gloss over is the data preparation. Your training data needs to be structured as input/output pairs in JSONL format, essentially teaching the model: “when asked this, respond like this.” One example from my KBO dataset looked like:

{"input": "What was Moon Bo-gyeong's batting average during the 2024 season?", "output": "Moon Bo-gyeong’s batting average was .301 in the 2024 KBO season."}

Get that format wrong, and the training runs fine but the model learns nothing useful. Once the dataset is clean, the actual training call is straightforward:

trainer = SFTTrainer(
    model=model,
    train_dataset=dataset['train'],
    eval_dataset=dataset['test'],
    dataset_text_field='text',
    max_seq_length=2048,
    args=TrainingArguments(
        per_device_train_batch_size=2,
        gradient_accumulation_steps=4,
        num_train_epochs=3,
        learning_rate=2e-4,
        output_dir='kbo_checkpoints',
    )
)
trainer.train()

After training, you export the model and run it locally through Ollama.

The fine-tuned model learned patterns. It could speak with real familiarity about KBO teams and players. But here’s the problem with specific statistical data: fine-tuned models are confidently wrong in ways that will age badly. The model learned the language of the data, not the facts. When it didn’t know a number, it filled the gap with something plausible-sounding. In baseball, that’s embarrassing. In a business context, a wrong figure in a financial report, a patient record, a production defect rate becomes a liability.

Approach three: build a RAG. This is where I landed, and where most real-world data problems actually belong.

RAG or Retrieval-Augmented Generation, doesn’t ask the model to remember your data. It builds a retrieval layer that searches your actual data first, then hands the relevant results to the model as context. The model’s job becomes interpretation and presentation, not memorization. The model is the analyst. The retrieval system is the filing cabinet.

My KBO RAG chatbot runs entirely on my local machine. It indexes 5,289 player-seasons across all 10 KBO teams from 2016 to 2025, plus 1,571 player bios. When you ask about Hanwha Eagles’s 2024 roster, it retrieves actual JSON files from my dataset, formats the stats, and passes them to the LLM with a clear instruction: answer only from this data. No cloud API. No data leaving my machine. No guessing. The accuracy difference is not subtle.

This wasn’t my first time building a RAG for a real use case.

In 2022, when I co-founded a zero-knowledge social media platform for verified college students, we faced the same core problem. Students wanted recommendations on what to study to target specific careers. We had course catalogs from multiple US universities. The question was how to make that information actually useful in context.

We built a RAG pipeline referencing real course offerings from each university. When a student expressed interest in product management at tech companies, the system didn’t hallucinate a curriculum. It retrieved real courses from their specific school and surfaced relevant options. Grounded, personalized, accurate.

The lesson I took from that: the magic is never in the model alone. It’s in the retrieval layer, the data strategy, the system design that keeps the AI working with truth instead of probability.

Let me translate the baseball project into language that’s harder to ignore.

If your team is using a general-purpose LLM to draft copy or brainstorm campaign angles, that’s approach one. Useful. Saves time on first drafts. But it has no knowledge of your brand guidelines, last quarter’s performance, or what’s actually happening in your specific markets.

Now consider a large enterprise, say, Samsung. Decades of internal product data, engineering specs, global customer feedback, supply chain metrics. A fine-tuned model trained on that data would speak the language of the company fluently: valuable for internal knowledge management, onboarding, contextual documentation generation. But ask it for a specific defect rate from Q3’s production line, and if that number is off by half a percent, the consequences ripple.

This is also why many large enterprises aren’t rushing to push their data into cloud-hosted models. The interest in on-premises AI environments has grown significantly, running models locally, keeping proprietary datasets off third-party infrastructure entirely. Security around LLM and agentic deployments is no longer a footnote. It’s a board-level conversation. And for good reason: the more capable these systems get, the higher the cost of a breach or a leak.

For use cases requiring precision on real internal data, a RAG (or a hybrid architecture where the LLM retrieves from verified internal sources before synthesizing) is the right answer. The data stays grounded. The model stays in its lane.

Three approaches. Three different purposes. None of them inherently wrong. All of them wrong when applied to the wrong problem.

Most organizations are still evaluating AI by typing a question into a chatbot and judging the response. That’s like evaluating a pitcher by watching one warmup throw. It’s not a strategy.

Prompt engineering matters. But its real leverage shows up when a well-designed prompt becomes a component inside an agentic workflow where an AI agent retrieves data, applies reasoning, takes action, and feeds results into a downstream process. That’s when it stops being a conversation trick and starts being infrastructure.

What this requires is end-to-end understanding. Not just “we use AI.” Which kind? Grounded in what data? Embedded in which workflow? With what guardrails? Deployed where, and why?

The organizations that will lead the next phase aren’t the ones who adopted AI the earliest. They’re the ones who understood the setup.

Here’s the part that I think is worth sitting with.

The broadcaster spending hours preparing note cards, the analyst building spreadsheets from scratch, the marketing director assembling a quarterly report by hand, their work doesn’t disappear. But the hours of manual preparation, the risk of human error, the bottleneck of individual memory? That part is already being replaced. Not by AI that guesses. By AI that retrieves, grounds, and acts on real data.

The generalist who understands how to connect data, models, workflows, and business context that person is becoming increasingly valuable. Not the person who has heard of the concept, or who knows someone who knows. The work itself is becoming the proof.

Baseball season is almost here. And I’ll be watching with a RAG chatbot on my laptop, a fine-tuned model I trained in Colab, and a custom GPT built for baseball analysis. Three tools, each with a purpose.

The batting order matters. Know what you’re putting up to the plate, and why.

I’ve been reflecting on the quiet drift that happens in the age of AI. It’s the moment when the flood of accessible tools and instant knowledge makes everyone feel capable, yet most strategies still lean heavily toward consuming the next shiny thing instead of actually producing something useful with it. The lowered barriers and rapid distribution let individuals, teams, organizations, and even governments become AI-enabled overnight. But real leverage comes from creation, not from endless absorption of information and performance boosters.

This pattern echoes much of Derek Thompson’s Hit Makers: The Science of Popularity in an Age of Distraction, where he shows how virality is fueled by spectacle over substance. Algorithms reward what’s shocking or instantly digestible, drawing people into cycles of attention-chasing that feel productive but rarely are. In the startup world, this shows up as founders without a steady internal direction. Without that north star, it becomes natural to chase likes, shares, and perceived ecosystem status instead of solving concrete problems. Some VCs do the same by projecting deep operator wisdom they’ve never lived through, building rockstar images from the safety of their capital gatekeeping role. It’s cosplay masquerading as authority.

For me, the way out has always been to move decisively from consumption to production. Consumption is passive and seductive. You scroll AI trend threads, sign up for every new tool, read one more newsletter, and walk away feeling sharper and more in the game. But the momentum is mostly illusion. It’s like filling the tank repeatedly without ever turning the key. The energy leaks into distraction and external validation loops instead of building anything real.

Production is different. It’s active, grounding, and forces decisions. You channel attention into making and crafting solutions for specific pains, iterating on messy prototypes, shipping value that exists independently of applause. Consuming ten AI platforms can give you ideas. Building one tailored solution actually solves something. Take a custom AI wrapper that fixes a precise workflow bottleneck in your startup. Sure, some people roll their eyes and call it too easy or not innovative enough. Yet those same voices usually haven’t taken ten minutes to wire up a Google Gemini Gem with NotebookLM, which basically gives you a personal super brain for both work and life tasks. The moment you start building, clarity arrives on its own. What exact problem am I addressing? Who benefits right now? How does this measurably improve things? That line of questioning turns scattered habits into durable discipline and pulls you out of performative theater into genuine forward motion.

In my own path this shift was everything. Early days were heavy on consumption, such as podcasts on loop, newsletters stacked, tools trialed endlessly, because it felt like progress. It left me fragmented, always one step behind the next hype wave. When I flipped to production, prototyping something as unglamorous as automated pattern detection in user feedback data, the fog lifted. The work wasn’t viral material, but it produced results, sharpened my judgment, and tied directly to a north star of real value. Over months and years that orientation becomes protective: you stop performing for an audience and start creating for impact. Authenticity turns into armor against the mask.

That’s the discipline I’m still honing.

Recently, David, General Partner at Ethos Fund, asked me to explain, in my own words, how my latest venture, FMInsight, connects to my broader life mission and career vision. He wanted it straightforward and personal, not a slick pitch. So here’s a brief, honest reflection on the single thread that’s guided me for over twenty-five years.

I’ve always believed that knowledge should be open to anyone who seeks it, and that thoughtful use of data can make daily life calmer, smoother, and better - without creating extra hassle. That belief is why I build platforms, why I wrote a couple of practical Python books for beginners (I still love how Python handles data), and why I carve out time to mentor founders through programs like The Founder Institute and Ignyte. It’s never been about credit or visibility - it’s simply about passing on the tools and mindsets that help turn good ideas into something solid and enduring, whether I’m volunteering time or working in a deeper advisory role.

For the past twenty-five years of my professional career, I’ve put this into action by building data-driven systems in healthcare, logistics, travel, and education, always aiming to replace constant firefighting with calm, forward-looking decisions. FMInsight is just the newest step along the same path, now applied to the buildings and spaces we spend our days in - using smart data to ease stress and help operations teams stay ahead of problems.

At its core, every system I’ve created has been about giving people better control over the chaos around them - a doctor managing patients, a logistics lead tracking shipments, a student charting their career, or a facility team keeping everything running. FMInsight follows that exact impulse for the physical environments we rely on most. When we make those spaces more resilient and less reactive through spatial intelligence, the people inside them can focus on what truly matters instead of putting out fires.

That’s the kind of quiet, lasting impact I’m always chasing.

Entrepreneurship gets romanticized with the visible stuff. Beanbags. Cold brew. Flexible hours. Quirky job titles. None of that is the actual product.

The real product is outcomes: shipping, retention, revenue, trust, velocity, and resilience under pressure. And those outcomes are created by people, guided by standards, and repeated through systems.

Sports has been trying to teach us this forever.

A great example is Nick Saban’s coaching tree showing up in the NCAA College Football Playoffs. Different programs, different styles, different conferences, same root system.

• Curt Cignetti (Indiana) Wide Receivers Coach and Recruiting Coordinator (2007–2010) at Alabama

• Kirby Smart (Georgia) Assistant Head Coach and DB Coach (2007) and Defensive Coordinator (2008–2015) at Alabama

• Dan Lanning (Oregon) Graduate Assistant (2015) at Alabama

• Pete Golding (Ole Miss) Co-Defensive Coordinator and Inside Linebackers Coach (2018) and Defensive Coordinator and Inside Linebackers Coach (2019–2022) at Alabama

• Mario Cristobal (Miami) Assistant Head Coach, Offensive Line Coach, and Recruiting Coordinator (2013–2016) at Alabama

This isn’t just trivia. It’s a blueprint for building companies that win.

The “coaching tree” is what startups call culture and talent density

In football, a coaching tree forms when a program consistently produces leaders who can take the same principles elsewhere and win in new environments. In startups, you see the same phenomenon:

• Founders who produce future founders

• Early leaders who become repeat operators

• Teams that go on to build high-performing groups at other companies

• Alumni networks that become talent pipelines and investor magnets

The core lesson: your environment produces people, and people reproduce environments.

If your company is truly great, it won’t just ship product. It will ship leaders.

What Saban got right that founders often miss

1) Standards are the culture, not vibes

Championship programs are not built on motivational speeches. They are built on what is tolerated and what is demanded, every day.

Startup translation:

• Clear definition of “done”

• High-quality decision making under constraints

• Accountability that is fair and consistent

• A bias toward fundamentals: customer pain, unit economics, reliability, clarity

Perks do not create performance. Standards do.

2) Process scales when charisma stops working

A founder’s charisma can carry a team from 0 to 1. It cannot carry them from 10 to 100. Winning programs win because their process survives personnel changes.

Startup translation:

• Hiring rubrics that prevent “good talkers” from sneaking in

• Operating cadence: weekly execution, metrics, retros

• Playbooks for sales, onboarding, incident response, customer success

• Training and feedback loops that compound

When you are tired, busy, and stressed, you do not rise to your goals. You fall to your systems.

3) Recruiting is strategy

Notice how multiple names in that coaching tree held roles tied to recruiting, development, or foundational execution (wide receivers, DBs, line, defensive systems). In elite programs, recruiting is not HR. It’s the game.

Startup translation:

• Your hiring bar is your strategy

• Your onboarding is your retention strategy

• Your performance management is your speed strategy

• Your leadership bench is your risk management

“People first” does not mean “people comfort”

Some founders hear “people first” and translate it into comfort-first. That’s how you end up with a nice office and mediocre results.

People first means:

• Psychological safety and performance clarity

• Candor without cruelty

• High trust and high standards

• Coaching that upgrades the team, not just manages it

• A mission that makes the sacrifice feel worth it

People don’t join startups for stability. They join for growth, ownership, and impact. Respecting that means building an environment where their courage converts into results.

The leap of faith: what team members are really betting on

Joining an early-stage startup is like signing with a new program that promises a better future but has not won yet. The risk is real, and so is the opportunity.

If you want great people to take that leap, they are looking for evidence of three things:

1. Competence
   Does leadership know what “good” looks like?

2. Integrity
   Do words match actions when things get hard?

3. Trajectory
   Is there a realistic path to winning, or just optimism?

Perks are not evidence. Execution is evidence.

The investor angle: your VCs are part of your team, not just your cap table

Here’s where the sports analogy gets even more useful. A great program does not just pick talented players. It picks people who fit the system, buy into the standard, and elevate the locker room.

Founders should evaluate investors the same way.

Pick investors like you pick coaches:

• Do they develop teams, or just critique from the stands?

• Do they stay calm in losing streaks, or create chaos?

• Do they have pattern recognition that helps, or ego that distracts?

• Do they open doors that matter for your stage, your market, your hiring needs?

• Do they align with your time horizon, or push for shortcuts?

The wrong investor is like a coordinator who changes the playbook every week. You don’t just lose games. You lose trust, clarity, and momentum.

The right investor reinforces the standard, supports recruiting, and helps you build a program that outlasts a single season.

Build a company that produces winners elsewhere

Nick Saban’s coaching tree is a loud signal: the most valuable thing a program creates is not a trophy. It’s a repeatable way of winning, carried forward by people.

That is the most underrated startup goal too.

Yes, ship product.
Yes, chase revenue.
Yes, hit milestones.

But if you want something that lasts, build a company where:

• People grow faster than they expected

• Standards are clear and real

• Leaders are developed, not just hired

• Results speak louder than perks

• Partners and investors strengthen the culture, not dilute it

Because in sports and startups, the scoreboard is honest.

And the best legacy is a tree.