If your techs are writing the same ticket responses and runbooks every week, you're leaving money on the table.

I build software for managed service providers. I also run an internal AI system -- 263 reusable skills, 709 documentation files, multi-agent code review -- that lets me manage 51 active project repositories solo. I've spent a lot of time thinking about which types of companies benefit most from this kind of AI infrastructure.

MSPs keep showing up at the top of the list. Here's why.

You Already Have the Hard Part

A consulting firm called Every, which advises Fortune 500 companies and hedge funds on AI adoption, made an observation that stuck with me: "Companies with cultures of documentation are uniquely well positioned for AI."

Think about what your MSP runs on. Ticketing systems full of categorized issues and resolutions. Runbooks for every client environment. SOPs for onboarding, offboarding, escalation. Change management records. Network documentation. Client-specific playbooks.

That's not administrative overhead. That's AI context.

The reason most companies struggle with AI adoption is they have nothing for the AI to read. Their processes live in people's heads. They have to start from scratch -- documenting everything before AI can be useful.

You already did that work. Your ConnectWise tickets, your IT Glue runbooks, your onboarding checklists -- all of it is structured data that an AI agent can read, learn from, and act on. The infrastructure gap that stops other companies cold barely exists for you.

Three Workflows That Transform Immediately

I'm not going to give you a vague pitch about "AI-enhanced operations." Here are three specific MSP workflows where AI agents produce measurable results, with the math.

1. Ticket Triage and Response

Here's how it works today: a ticket comes in. Your tech reads it, figures out the category and severity, writes a response, and routes it to the right person or queue. That's 10-15 minutes per ticket when you account for reading client history and checking the knowledge base. Your team handles dozens of these per day.

With an AI skill built on your response templates and client context: the agent reads the ticket, classifies severity based on your criteria, drafts a response using your template library, and routes it to the right tech. Your tech reviews the draft, makes adjustments if needed, and sends. Total time: 2-3 minutes.

The math: 30 tickets per day x 10 minutes saved per ticket = 5 hours recovered per tech, per day. If you have 5 techs handling tickets, that's 25 hours per day -- over 500 hours per month. At a blended cost of $40/hour, that's $20,000/month in recovered capacity. Not savings on paper. Actual hours your techs can spend on project work, escalations, or going home on time.

2. Runbook Generation

You know the pattern. A senior tech solves a novel issue. They should write it up so the next person can handle it. It would take 1-2 hours to write a proper runbook. They're busy. The runbook doesn't get written. Three months later, a junior tech hits the same issue and escalates it because there's no documentation.

With an AI skill: the agent reads the ticket history, the resolution steps, the client environment details, and generates a runbook in your standard template format. Your senior tech reviews it and approves. Fifteen minutes instead of two hours.

But the bigger win isn't the time savings. It's that the runbooks actually get written. Every resolved ticket becomes a potential knowledge base article. Your junior techs handle more independently. Your escalation rate drops. Your clients get faster resolution times.

The math: If your team resolves 20 novel issues per month and each runbook saves 1.5 hours, that's 30 hours/month in writing time recovered. More importantly, if those runbooks prevent even 10 escalations per month at 30 minutes each, you save another 5 hours -- and your clients notice the faster response.

3. Client Onboarding Documentation

Every new client means a stack of documentation: network diagrams, contact lists, escalation procedures, environment details, password vaults, monitoring configurations. Your project manager fills out templates manually, pulling data from the PSA tool, network scans, and discovery calls. It takes 4-8 hours per client.

With an AI skill connected to your PSA and documentation tools: the agent pulls the data that already exists, generates the onboarding docs in your format, and flags gaps that need human input. Your PM reviews, customizes the sections that need a human touch, and fills the gaps. Total time: 1-2 hours.

The math: 3 new clients per month x 5 hours saved per client = 15 hours/month. Scale that to 5 new clients and it's 25 hours. But the real value is consistency -- every client gets the same thorough onboarding, not a rushed version because your PM was handling three onboardings simultaneously.

The Multiplier Effect

Here's the part most people miss about MSPs and AI.

You manage other companies' technology. When your internal AI workflows work well, you're not just saving your own time. You're delivering better service to every client in your portfolio. Faster ticket responses. Better documentation. More thorough onboarding.

That's a premium positioning. "AI-enhanced managed services" isn't a marketing gimmick if you can actually demonstrate it: here's your average ticket response time before, here it is after. Here's the number of runbooks in your knowledge base last quarter versus this quarter. Here's how many issues your junior techs resolved without escalation.

Your clients feel the difference even if they never see the AI behind it. And when they ask -- and they will -- you have a story to tell.

The Compliance Angle You Can't Ignore

Your clients are already asking about AI. Maybe not directly, but it's showing up in their security questionnaires. "How does your organization govern AI usage?" "What data is processed by AI tools?" "Do you have an acceptable use policy for AI?"

If your answer today is "we don't have a formal policy," you're not alone. Most MSPs don't. But the window for that being an acceptable answer is closing.

SOC 2 auditors are adding AI controls to their assessments. Cyber insurance applications are asking about AI practices. Your enterprise clients -- the ones paying the highest monthly recurring -- are the most likely to require documented AI governance.

Having a documented AI governance framework -- acceptable use policy, data classification for AI tools, risk assessment -- answers those questions before they become problems. It also differentiates you from every other MSP that's winging it.

We built a full ISO 42001 governance framework for ourselves -- 30 documents covering policies, procedures, risk assessment, and audit programs. We're pursuing certification by Q4 2026. The same framework scales down for MSPs who need governance without the full certification process.

What This Looks Like in Practice

We build software for MSPs. We know your PSA tools, your ticketing workflows, your documentation platforms, and the compliance pressure you face from clients and auditors.

Here's what an engagement looks like:

Week 1: We assess your current AI maturity, audit your top workflows, and identify the 5-10 highest-value opportunities. We set up your CLAUDE.md -- the configuration file that ensures every AI tool follows your standards -- and sync it across your team's tools.

Week 2: We build 5-10 custom skills for your specific workflows. Ticket triage using your response templates. Runbook generation in your documentation format. Client onboarding with your PSA integration. Your techs start using them immediately. No coding required on their end.

Ongoing: Your team extends the skill library as they find new workflows to automate. We provide support as AI tools evolve -- and they evolve monthly.

The infrastructure we deploy is the same system we run internally. It's not theoretical. We depend on it every day to manage our own workload.

The Bottom Line

MSPs are documentation cultures operating in a world where AI runs on documentation. The alignment is natural. The workflows are repetitive and well-defined. The math on time savings is straightforward. And the compliance angle gives you a competitive edge that most of your competitors haven't started thinking about.

Your techs shouldn't be writing the same ticket responses every week. They should be reviewing AI-drafted responses and spending their time on the work that actually requires a human.

The practical next move is to identify the three highest-frequency support workflows in your shop, document them clearly, and test where AI can reduce repetition without breaking trust or escalation quality.

I run Namos Labs, a human-first AI product studio focused on practical systems design, workflow leverage, and products that help teams move from experimentation to durable execution.

A client's security questionnaire asked "How do you govern AI usage?" We didn't have an answer. So we built one.

That single question on a vendor assessment form set off a chain reaction. Not because we were doing anything wrong -- but because we had no way to prove we were doing things right. AI was woven into everything we do: Claude Code for building features, Copilot for code suggestions, ChatGPT for research and drafting. We had 263 Claude skills, 51 active repositories, and a fully AI-native workflow. But when it came to governance, we had nothing documented. No policy. No inventory. No risk assessment.

The honest answer to that questionnaire was "we don't govern AI usage." And when you build software for clients who trust you with their data, that's not an acceptable answer.

Why We Picked ISO 42001

We could have written a one-page AI policy, called it done, and moved on. That would have answered the questionnaire. But it wouldn't have solved the actual problem.

ISO 42001 is the international standard for AI management systems. It's comprehensive -- it covers governance, risk management, policies, monitoring, and continuous improvement. It's also relatively new, which means most companies haven't implemented it yet. We saw an opportunity to get ahead of what's coming rather than scramble to catch up later.

SOC 2 auditors are already asking about AI controls. Enterprise clients want to see AI policies before signing contracts. The EU AI Act is creating new requirements that will affect companies doing business in Europe. These aren't theoretical pressures. We were already fielding these questions from prospects and clients.

So we decided to pursue the full framework. Not just a policy document -- the complete management system.

What We Actually Built

30 documents across 6 phases. Here's what that breaks down to:

Phase 1: Foundation and Gap Analysis. We started by figuring out where we stood. A clause-by-clause assessment of ISO 42001 requirements against our current practices. This was humbling. We had strong engineering practices but almost no formal governance documentation.

Phase 2: Risk Assessment and Treatment. Every AI use case cataloged, classified by risk level, and assessed for likelihood and impact. We built a risk register, defined treatment plans for high-risk items, and set acceptance criteria for what level of risk is acceptable.

Phase 3: Policy and Objective Setting. The actual policy documents: acceptable use policy, data classification for AI, tool configuration standards, incident response procedures for AI-specific issues like bias detection, data leaks, or hallucinations making it into production.

Phase 4: Implementation and Operation. Roles and responsibilities. Decision authority matrices. Escalation paths. Who approves new AI use cases. Who reviews the risk register. How we evaluate new AI tools before adopting them.

Phase 5: Performance Evaluation. KPIs for AI governance. An internal audit checklist. A management review process. Quarterly self-assessment templates. The mechanisms that keep governance alive instead of letting it rot in a shared drive.

Phase 6: Certification Readiness. A pre-certification action plan. Gap remediation tracking. The documentation package an auditor would need to see.

We built all of this in days, not the typical 6-12 months. That sounds impossible until you consider that we used AI to help build its own governance framework. Claude helped draft policies. We used our existing documentation infrastructure -- 709 files, 278,000+ lines -- as context. The same AI-native workflow that powers our engineering work powered the compliance work.

Meta? Yes. But it also proved the point: AI infrastructure compounds. The investment we'd made in documentation and skills paid off in a domain we hadn't originally built it for.

What Surprised Us

1. It wasn't as heavy as we expected. Most of what ISO 42001 asks you to do is stuff you should already be doing -- documenting how you use tools, assessing risks, defining who's responsible for what. The framework just gives it structure. If you already have decent engineering practices, you're further along than you think.

2. The hardest part was the inventory. Writing policies was straightforward. Cataloging every single way we use AI was not. It's easy to list the obvious tools -- ChatGPT, Claude Code, Copilot. It's harder to remember that your CI pipeline uses an AI-powered code scanner, your documentation tool has AI features you enabled six months ago, and someone on the team signed up for an AI transcription service for meeting notes. You can't govern what you don't know about.

3. Risk assessment forced uncomfortable conversations. We had to sit down and honestly evaluate: what happens if this AI tool hallucinates in this context? What happens if client data gets sent to a model we haven't vetted? What happens if an AI-generated code suggestion introduces a security vulnerability that passes code review? Some of those scenarios had non-trivial consequences we hadn't thought through.

4. The framework made our AI usage better, not slower. This was the biggest surprise. We expected governance to be a tax -- more process, more friction, less speed. Instead, it clarified our practices. The data classification policy meant everyone knew exactly which data could go into which tools. The tool configuration standards meant consistent privacy settings across the team. The incident response procedure meant we had a plan instead of panic. Governance didn't slow us down. It removed ambiguity that was already slowing us down; we just hadn't noticed.

5. AI was genuinely good at building its own governance. We used Claude to draft policies, generate risk assessment templates, and structure the audit program. It had access to our operating system documentation, understood our workflows, and produced drafts that needed editing -- not rewriting. The irony of using AI to govern AI isn't lost on us, but the output speaks for itself.

What We'd Do Differently

Start with the AI system inventory. We began with gap analysis, which is what the standard suggests. In hindsight, we should have started by cataloging every AI tool and use case first. The inventory informs everything else -- you can't assess gaps or risks against systems you haven't identified. If you do one thing this week, start a spreadsheet of every AI tool your organization uses, who uses it, and what data it touches.

Don't try to do all 6 phases at once. We had the advantage of a small team and strong documentation infrastructure. If you're a 50-person company, trying to build the entire framework simultaneously will overwhelm people. Start with Phase 1 (gap analysis) and Phase 2 (risk assessment). Those two phases give you the biggest return because they tell you where you actually stand and where the real risks are. The policies can come after.

Get leadership buy-in early. AI governance dies if only engineering cares about it. The acceptable use policy affects marketing, sales, customer support -- anyone who touches AI. The risk register needs input from people who understand business impact, not just technical risk. If your CEO doesn't understand why this matters, the framework becomes shelfware.

The Honest Disclosure

We are pursuing ISO 42001 certification. We are not certified. Our target is Q4 2026.

I'm being explicit about this because I've seen too many companies imply credentials they don't have. We built the framework. We use it daily. We believe it's solid enough to pass an audit. But we haven't gone through that audit yet.

Here's why I think that honesty is actually a strength: we're in the same position as most of the companies we work with. We know exactly which parts of the process are hard because we just went through them. We know where the gotchas are. We know which documents took three drafts to get right and which ones were straightforward. We're not selling from a textbook or reciting what we learned in a certification course. We're sharing what we built, what worked, what didn't, and what we'd change.

If you need someone who's already certified to stamp your documents, you need an accredited certification body. We're not that. What we are is practitioners who can get you ready for that engagement -- so when you do hire the certification body, you're prepared rather than starting from scratch at their billing rate.

Who Needs This Now

Not everyone needs ISO 42001 compliance today. But some companies need to start yesterday.

If your clients ask about AI in security questionnaires. This is the trigger that started our journey. If you're fielding these questions and scrambling for answers, you need at minimum an AI policy framework and a system inventory.

If you're an MSP managing other companies' technology. Your clients are asking you about AI governance because their auditors are asking them. Having documented AI practices isn't just good hygiene -- it's a competitive differentiator when you're bidding for contracts.

If you handle sensitive data with AI tools. Legal tech companies processing contracts. Healthcare companies using AI for patient communications. Financial services companies using AI for analysis. If the data is sensitive, the governance isn't optional.

If you're thinking about the EU AI Act or SOC 2 AI controls. These aren't hypothetical anymore. SOC 2 auditors are actively asking about AI. The EU AI Act has compliance deadlines. Getting the foundation in place now is cheaper than rushing to comply under a deadline.

If "everyone uses AI however they want" describes your organization. That's where we were. It felt fine until someone asked us to prove it was fine. The gap between "we use AI responsibly" and "here's the documentation proving we use AI responsibly" is the gap that governance fills.

What We Offer

We took everything we built for ourselves -- 30 documents, 6 phases, the full ISO 42001 framework -- and turned it into a service we call AI Governance Readiness. We adapt our framework for your company: your size, your industry, your AI usage, your compliance targets.

The engagement runs 4-6 weeks. You get an AI system inventory, a policy framework, risk assessments, a governance structure, a compliance gap analysis, and monitoring foundations. These aren't empty templates. They're our working documents with real content, customized for your organization.

We deliver everything into your repository, not ours. We train your team on how to maintain it. When we leave, the framework keeps working.

If you're facing questions about AI governance -- from clients, auditors, regulators, or your own leadership team -- and you don't have answers yet, the practical next step is to document current usage, identify control gaps, and define what “audit-ready” should mean for your team before you buy tooling or policy theater.

I run Namos Labs, a human-first AI product studio. We're pursuing ISO 42001-aligned governance because we think practical AI controls are going to become table stakes very quickly.

Your team is using AI. But are they using it at Level 1, or Level 3? The difference is 10x.

I talk to engineering managers and team leads every week who tell me some version of the same story: "We're using AI, but it just feels like a faster Google." They have developers copy-pasting into ChatGPT, accepting the first answer, and moving on. Some have Copilot licenses. A few have experimented with Cursor or Claude Code.

None of them have infrastructure.

After building an AI system that lets me manage 51 active project repositories solo, I've come to see AI adoption as a ladder with four distinct levels. Most teams are stuck on the first rung -- not because they lack talent or ambition, but because nobody owns the climb.

Here's the framework.

Level 1: Chat-Based AI

Tools: ChatGPT, Claude chat, Gemini

This is where 80%+ of companies sit today. Someone on the team discovered ChatGPT, started using it for drafting emails and debugging error messages, and told a few coworkers. Now half the team uses it sometimes. The other half thinks it's a toy.

Signs you're here: there are no shared standards for how AI gets used. Everyone prompts differently. Nobody trusts AI output for anything that matters. When someone gets a bad result, they stop using it for that task entirely.

The value at Level 1 is real but modest -- some time savings on drafting, research, and brainstorming. The problem is that it stays modest. Without infrastructure, individual experimentation never compounds into organizational capability.

This level is a dead end unless someone deliberately builds the bridge to Level 2.

Level 2: IDE-Integrated AI

Tools: Cursor (agent mode), Claude with skills, CLAUDE.md, ai-rules-sync

Level 2 is where AI starts reading your codebase, following your coding standards, and using reusable skills for common tasks. Instead of copy-pasting context into a chat window, the AI already knows your stack, your patterns, and your conventions.

Signs you're here: you have a CLAUDE.md or similar standards file. Your team has built reusable skills -- saved instruction sets for recurring workflows like feature planning, code review, or deployment. Everyone uses the same tools with the same configuration. When someone gets a bad AI output, they update the skill, not just their prompt.

This is where the biggest productivity jump happens. The difference between "everyone prompts their own way" and "shared skills that encode best practices" is enormous. I've seen teams go from treating AI as a novelty to treating it as essential infrastructure in under two weeks once the right foundation is in place.

This is also where what I call the "100-hour head start" matters most. Setting up CLAUDE.md files, building skills, configuring ai-rules-sync across tools, creating quality scoring systems -- this takes hundreds of hours to figure out from scratch. Most teams stall here because the setup work isn't anyone's job.

Level 3: Agentic AI

Tools: Claude Code, MCP integrations, background tasks, local data access

Level 3 is the shift from "AI assists me" to "AI works for me." Agents run multi-step tasks autonomously. They're connected to your internal data through MCPs -- databases, APIs, file systems. You give a high-level instruction and the agent figures out the steps.

Signs you're here: you're running Claude Code or similar tools that execute multi-step workflows without hand-holding. AI agents handle code review, feature planning, security audits, and report generation. You spend your time making decisions, not doing busywork.

Tasks that took hours now take minutes. A feature spec that required half a day of research and writing gets generated, scored against a quality rubric, and refined in under 20 minutes. A code review that one senior engineer used to do alone now gets done by six specialized agents checking security, performance, architecture, patterns, testing, and style -- before a human even looks at it.

This is also where governance becomes non-optional. When agents are running autonomously and connected to internal data, the question "who's watching the agents?" needs a real answer. You need policies, monitoring, and review processes. Without them, you're scaling risk alongside productivity.

Level 4: Multi-Agent Orchestration

Tools: Parallel Claude Code sessions, agent swarms, custom dashboards, CI/CD integration

Level 4 is where one person does team-level work. Multiple agents run simultaneously -- one reviewing code, one writing tests, one running security analysis, one generating documentation. Quality goes up because more reviewers (even AI reviewers) catch more problems.

Signs you're here: you're running 2-3 agent sessions in parallel. Quality enforcement is automated. You have a skill library with dozens or hundreds of reusable workflows. Your AI infrastructure is version-controlled, synced across every tool, and maintained like production code.

This is where I operate internally. It's not magic. It's infrastructure -- 263 skills, 709 documentation files, automated quality scoring, multi-agent code review. It took months to build. But now the system compounds. Every postmortem, every new skill, every standards update makes every agent smarter across every project.

Why Teams Get Stuck

Each transition has a specific failure mode.

Level 1 to Level 2: Nobody owns it. AI adoption happens individually. Engineers experiment on their own. There's no shared CLAUDE.md, no skill library, no synced standards. Without someone taking ownership of the infrastructure, individual experiments never become team capability. This is the most common gap I see.

Level 2 to Level 3: Documentation goes stale. Agentic AI follows your documentation literally -- including the outdated parts. If your CLAUDE.md references a pattern you deprecated three months ago, the agent will use it. The teams that succeed at Level 3 are the ones that treat their AI context like production code: maintained, reviewed, and current.

Level 3 to Level 4: Trust breaks down. Running multiple agents in parallel requires organizational discipline. You need confidence that your skills produce consistent quality, that your review processes catch errors, and that your governance framework covers the expanded surface area. Teams that skip governance at Level 3 can't scale to Level 4 because they don't trust the output enough to run unsupervised.

The Infrastructure Is the Differentiator

Here's the insight that changed how I think about AI adoption: the model you use barely matters. GPT-4, Claude, Gemini -- they're all getting better every month. They'll keep getting better. The model is a commodity.

What separates teams that get 10x value from teams that get marginal value is the infrastructure wrapped around the model. The CLAUDE.md that encodes your standards. The skills that capture your best practices. The review processes that catch errors. The documentation that gives agents context. The governance framework that lets you scale with confidence.

A company I respect, Every -- they consult with Fortune 500s and hedge funds on AI strategy -- put it clearly in a recent webinar: "Companies with cultures of documentation are uniquely well positioned for AI." That rings true in everything I've seen. The companies that already document their processes, maintain their knowledge bases, and standardize their workflows are the ones that move fastest from Level 1 to Level 3. The documentation IS the AI context.

Where Do You Stand?

If you read through these levels and thought "we're mostly at Level 1" -- you're in the majority. That's not a judgment. It's an opportunity.

The jump from Level 1 to Level 2 is the single highest-ROI move most teams can make. It doesn't require new hires, new tools, or a six-month transformation initiative. It requires someone building the right infrastructure: a CLAUDE.md, a set of skills for your top workflows, and a sync system that keeps everything consistent.

We built a maturity assessment -- 12 questions across AI usage, infrastructure, quality, and governance -- that maps directly to these four levels. It takes 5 minutes and gives you a concrete score plus specific recommendations for what to do next.

I run Namos Labs, a human-first AI product studio. The operating model behind these levels is the same kind of systems thinking we apply across our own products and internal workflows.

I manage 51 active project repositories. My team size is 1.

That's not a flex. It's an infrastructure problem I had to solve. I run an experiential tech company that builds software for MSPs, legal tech companies, and marketing tech companies. I also maintain our own products. At some point the number of codebases crossed a threshold where traditional project management -- Jira boards, weekly standups, careful context switching -- stopped working.

The usual answer is "hire more people." Instead, I built an operating system that makes AI agents do most of the work that used to require a team.

Here's what that actually looks like.

The Operating System

Everything starts with documentation. Not the kind that sits in a Confluence page nobody reads. The kind that AI tools read automatically every time they start a session.

My internal OS is a single git repository: 709 markdown files, 278,000+ lines. It covers company policies, engineering standards, security playbooks, compliance frameworks, postmortem templates, and architecture decision records. Every department has a handbook. Every process has a checklist.

This isn't overhead. This IS the infrastructure. When I open Claude Code on any of those 51 projects, it reads the CLAUDE.md file and immediately knows my coding standards, my deployment patterns, my security requirements, and how I like things done. I don't re-explain anything. The documentation is the onboarding.

263 Skills

Skills are reusable instruction sets -- like SOPs for AI agents. Instead of explaining what I want each time, I run a command.

/feature-plan generates a complete feature specification with architecture decisions, component breakdown, and implementation steps. A different skill, /planning-qa, scores that spec on a 100-point rubric. Anything below 90 gets reworked. The generator and the checker are separate -- the AI doesn't grade its own homework.

/gcam commits all changes (excluding .env files) and pushes to main. /code-review spins up 6 specialized agents -- security sentinel, performance oracle, architecture reviewer, pattern recognition specialist -- that review code from different angles before any PR gets created.

I have 263 of these skills. They cover feature planning, code review, deployment, security audits, content creation, SEO optimization, email campaigns, and more. Every skill is synced across Claude Code, Cursor, and Codex using a tool called ai-rules-sync. Every AI tool I touch follows the same standards and has access to the same workflows.

Building these took months. Using them takes seconds.

A Typical Day

Morning: I open my prioritized task tracker. Claude Code reads the context and proposes a work plan.

Building: I pick a project, run /feature-plan to generate the spec, run /planning-qa to score it. If it passes, I start implementation. Claude Code reads the project's CLAUDE.md, follows the coding standards, and builds with awareness of the architecture.

Reviewing: Before every PR, the multi-agent code review runs. Six agents check security, performance, architecture, patterns, testing, and style. I focus my review on business logic and edge cases -- the stuff AI still misses.

Shipping: Deployment checklists are encoded in skills. Pre-commit hooks catch secrets via gitleaks. The deployment skill knows the pattern: dev branch goes to staging, main goes to production.

Learning: When something breaks, a postmortem gets written. Not a blame document -- a structured learning that feeds back into the skills and checklists. I have 15 postmortem reports so far. Each one made the system smarter.

What Doesn't Work

I'm not going to pretend this is seamless.

Running too many sessions at once. I've tried 4-5 Claude Code sessions in parallel. The context switching is brutal. You're not coding anymore -- you're managing, and you didn't sign up for that. Two to three concurrent sessions is my practical limit.

Trusting agent output without review. AI-generated code looks professional. It compiles. It often passes basic tests. And then it has a subtle bug that only shows up in production. The "plausible but wrong" trap is real. Every agent output gets reviewed, period.

Skipping documentation. There was a phase where I thought I could move fast and document later. That's the fastest way to make your AI agents useless. They're only as good as the context they can read. Stale docs produce stale output.

Expecting AI to understand business context. AI is great at "how." It's bad at "why." It'll build exactly what you ask for without questioning whether it should exist. The decision-making is still mine.

The Numbers

• 51 active project repositories
• 263 Claude skills
• 709 documentation files
• 278,000+ lines of documentation
• 30 ISO 42001 compliance documents (built in days, not months)
• 14 security incident response playbooks
• 15 postmortem reports
• 7 engineering checklists

All managed by one person with AI agents.

Why I'm Sharing This

I build software for MSPs, legal tech companies, and marketing tech companies. The AI infrastructure I use internally is the same system I deploy for clients.

When a client hires us, they don't start from zero. They get the 100-hour head start -- everything I figured out through trial and error about where skills should live, how to sync standards across tools, how to set up code review agents, how to structure a devkit. We customize it for their team, their stack, their workflows.

Most companies I talk to are stuck at what I call Level 1: copying and pasting into ChatGPT and accepting whatever comes back. They know AI can do more but don't know how to get there.

The gap isn't knowledge. It's infrastructure.

If you're curious where your team stands, start with the maturity assessment and map the biggest opportunities in your workflow, standards, and governance setup before you chase more tooling.

I run Namos Labs, a human-first AI product studio focused on systems, software, and practical operating models for teams adopting AI.

In today's digital landscape, software has become increasingly complex, often prioritizing features and functionality over the people who use it. Human-first software represents a fundamental shift in how we design and build applications—placing people at the center of every decision.

What is Human-First Software?

Human-first software is built on the principle that users matter more than features. It eliminates unnecessary friction between what users want to accomplish and the outcome they seek. Instead of sprawling feature lists and confusing pricing tiers, human-first applications are designed to be intuitive, efficient, and delightful to use.

The Problem with Feature-Driven Design

Historically, software companies have measured success by feature count. More features meant more value—or so they thought. But this approach creates obstacles that drain user energy and attention. Users encounter cluttered interfaces, overwhelming options, and countless interruptions that stand between their intent and results.

The Solution: Reducing Obstacles-to-Value

Human-first design introduces the concept of Obstacles-to-Value (OTV)—the total effort embedded in a system through interactions, decisions, and interruptions. By minimizing OTV, software becomes:

• Clear: Information is presented simply and directly
• Efficient: Users achieve results with minimal effort
• Natural: The interface feels intuitive and human-centered
• Fast: Reduced friction translates to improved performance

Why It Matters

Applications that prioritize human needs feel faster, more intuitive, and more modern. They build loyalty and drive adoption naturally. Users don't just tolerate these products—they love them.

The Future

As competition intensifies, software that ignores human experience will feel outdated. The future belongs to products that respect users' time and intelligence, delivering value without friction.

Building human-first software isn't just good UX—it's essential for success in a crowded marketplace.