The Apparatus: Building the Machine That Runs While We Don't

There's this phrase floating around TwelveLabs right now: Tokens Never Sleep. But before it was a phrase, it was a question. And honestly, the way it started is the best part of the story.

It Started with a Dashboard

A couple weeks ago, our CEO Jae saw one of our team members wire up a finance tool to an LLM, connect it to our data, and the thing just produced a polished dashboard. Real analysis, real output. Speed and working smarter aren't the vision here; they're the default. What caught Jae's attention was something bigger: 'Can we connect more?

I said, "Let's try."

So I built a competitive analysis skill inside the LLM. Wired it up to our CRM, our knowledge base, web search. Hit go. The LLM produced a competitive dashboard that would've taken someone a full day to put together manually. Jae looked at it and asked the question that changed everything: "Can everyone have this? Can we make this work while we sleep?"

That's where "Tokens Never Sleep" was born. Not as a marketing line. As a real operational question: what if AI copilots could handle the repetitive cognitive work: triaging tickets, provisioning systems, chasing updates, continuously, 24/7, while we focus on the work that actually requires human judgment?

One Copilot: The Proof of Concept

We started with one copilot. Mine.

Here's the thing about IT at an AI company. You can build the most sophisticated video AI models on the planet, but if someone can't get their accounts provisioned, or a permissions error blocks an engineer at midnight, or an internal tool goes down during the timezone gaps across continents, productivity grinds. Traditional IT handles this with ticketing queues and SLA timers. Somebody files a request, it sits, a human gets to it during business hours, there's a back-and-forth. That model doesn't work when you're split across multiple timezones.

So I built my own copilot. It knew my role, my tools, my priorities. I gave it skills: ticket triage, access provisioning, identity management, security monitoring, device management. One copilot running real operational work, not a demo.

And it worked. Here's what "worked" looks like in numbers: routine access requests went from 8-hour resolution times to basically 15 minutes. Onboarding went from a full business day per new hire (me clicking through admin consoles) to a 10-minute review. New hires get everything on day one instead of day three. And 60% of routine IT tickets now close without a human touching them. The other 40% arrive in my queue pre-diagnosed with full context attached e.g. here's what was checked, here's what was found, here's the recommended action.

We now have copilot watching our ticketing system at all hours.

The Expansion: From One Copilot to a Network

Once one copilot worked, the obvious next question was: what if everyone had one?

So we built the communication layer. Every person at TwelveLabs gets a personal copilot that knows their role, their active projects, their tools, their permissions. But here's what makes this more than just "everyone gets a chatbot." The copilots can discover each other's skills and route tasks between them.

Say it's 2AM in San Francisco, 6PM in Seoul. A Seoul-based engineer hits a permissions error on a new internal tool. Their copilot recognizes the issue, pings my copilot's provisioning skill to check the permission matrix, cross-references with the security monitoring skill to confirm there's no outage, and resolves the access request, all in minutes. Old world, that engineer is blocked until I wake up and check my queue in the morning. New world, it's handled before they finish their current thought.

And here's the part that matters for trust: every cross-copilot action requires human approval in Slack. No copilot acts without consent. The system is fast, but it's not unsupervised. When something needs a judgment call, it escalates with the full context already assembled. The human just decides.

The troubleshooting piece works the same way. When someone reports that "this internal app is being weird", which, honestly, is about 30% of tickets, the copilot network correlates that vague report with system logs, recent changes, and similar past incidents. By the time a human looks at it, "weird" has been translated into an actual diagnosis.

IT as a Builder, Not Just a Fixer

Here's where it gets really fun. The initiative runs on three principles: Speed Over Perfection (ship in hours, iterate on feedback), Demo-Driven Development (if you can't demo it, question whether it's worth doing), and AI-First Thinking (before any task, ask "Can AI do 80% of this?").

That last one completely changed what IT looks like at TwelveLabs. We used to get requests like: "Can we get a simple dashboard to track X?" or "Is there a tool that does Y?" And the answer was always some version of "let me look into it" followed by a two-week procurement process or a request to engineering that would sit in a backlog for a month.

Now? I build internal tools in hours. Not days. Hours. And it's not just me, teams across the company are shipping their own tools under the initiative. Finance built a dashboard. Recruiting built a sourcing app. We turned side projects into production ready tools with the "Can AI do 80% of this?" mindset.. You start with AI, you ship a demo, you iterate based on feedback. Speed over perfection.

IT went from the department that says "we'll get back to you" to the department that says "let me show you something." That happened because the copilots handle the maintenance and firefighting that used to eat 70% of my time.

Build for the Gap

Every system decision I make gets tested against the same scenario: both offices are asleep. The SF team logged off, the Seoul team hasn't started yet. There's a window every single day where no human at TwelveLabs is working. What happens during that window?

If the answer is "nothing", that's a problem. And if the answer is "a human has to wake up", that's also a problem. The copilots should be handling it. Not because humans aren't valuable, but because human attention is a finite resource and we should spend it on things that actually require human judgment. Approving a routine access request at 2AM is not that. Deciding the architecture for a new internal platform is.

Tokens never sleep so that we can. And honestly? I sleep a lot better these days.

Rick Mondragon is the IT Manager at TwelveLabs, where he runs infrastructure and internal systems across San Francisco and Seoul.