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.