I didn't build 12 AI employees. I installed them.

The official Grok Bot Marketplace already has a project manager, engineer, designer, writer, recruiter, outbound rep, procurement agent, office ops and more.

The part I actually needed to figure out was everything between them.

Who gets the next task?
Is the research actually good enough?
Should the agent continue or stop?
Is the project really done?
Does this action need me?

SpaceXAI already describes the first half of this setup:

“People inside SpaceXAI often run multiple Bots in parallel, with one to manage the others”

Grok Bot started as an internal prototype and spread across the company into sales outbound, marketing, operations and engineering workflows. Bots can message each other, share context and coordinate in groups.

So I wanted to add one thing:

a decision layer between the manager and the workers.

That is where Jev gets interesting.

TypeSafe describes Jev as:

“unstructured state in, typed probabilistic decisions out.”

It gives up open-ended string generation and focuses on decisions that software can use directly: choose, score, classify, route, verify.

TypeSafe currently reports an input price of $0.042 per million tokens and no metered output-token charge; its speed claims are for System-One-shaped workloads, not arbitrary LLM tasks.

That gives us a very clean split:

Grok Bot creates the work → Jev decides what happens next → code/tools execute → human stays on the dangerous edges.

This is the setup I wanted.

And you can copy almost all of it.

01. Don't build the company from scratch

My first rule was simple:

if the Grok Bot team already built a specialist for the job, I'm not rebuilding it.

The Marketplace has a dedicated From Grok Bot Team section with ready-made Bots you can add directly.

This is the base company I would install:

Every one of those descriptions comes from the current Grok Bot Team Marketplace, not roles invented for this article.

I intentionally wouldn't install every Bot on day one.

There are excellent extras like Stalk Bot, Pipeline Pulse, Signal Prospector, Deal Inspector, Company Docs Q&A and Nightly Audit Engineer.

But adding agents because they exist is exactly how an agent setup becomes a mess.

Start with jobs you actually have.

02. Make one Bot the only Bot you talk to

Twelve workers are useless if I still have to manually decide which one to message every time.

So I needed one front door.

I picked Projects Manager.

Its Marketplace description is almost suspiciously perfect for this: it coordinates projects, lets specialist Bots claim work and does not do specialist work itself.

That matches how SpaceXAI says people inside the company already use multi-Bot setups: a chief-of-staff-style Bot sits above specialists, with agents handing work between themselves instead of forcing the human to be the middleman.

I would add this to Projects Manager:

You are the front door for this company.

Own coordination, not specialist execution.

For every request:

Never pretend delegated work happened. Never mark a non-trivial objective complete without evidence. Never take over a specialist's job just because it is faster to do it yourself.

Now I have one inbox.

But I still have a problem.

Projects Manager is both coordinating the work and making every tiny judgment inside the coordination loop.

Who goes next?
Did the researcher find enough?
Is this done?
Should we retry?

Those questions do not need another essay from a frontier LLM.

They need decisions.

03. This is where Jev finally makes sense

Jev is easy to misunderstand if you approach it as another model you should chat with.

I wouldn't.

TypeSafe calls it its first System One Model: instead of asking for arbitrary generated text, your software defines the possible outputs first.

Jev currently supports three basic decision primitives:

Choice Pick one option from a set and return a probability distribution plus confidence.

Score Evaluate something against an ordered scale.

Noul Answer a yes/no question as a probability of “yes.”

So instead of asking:

“Think deeply about which of my 12 agents should handle this task, explain your reasoning, then output JSON.”

I can give it the current state and a fixed menu:

Who should act next?

That is a much better fit.

The generative agent keeps generating.

The decision model handles the fork.

Grok does the job. Jev decides where the job goes next.

04. I almost wrote the integration myself

Then I noticed something funny.

There is already a Grok Marketplace Bot called tinkabot.

Its job:

wrap an API into a Cursor/Agent Plugin using MCP + skills, start from the data shape, build the smallest scaffold that works and prove it locally.

That is literally the integration I need.

So instead of spending the article teaching you how to hand-write an MCP server, I would use the Grok Bot Team's own integration Bot to turn the official TypeSafe API into our company decision plugin.

This is the first prompt I would give tinkabot:

Build an Agent Plugin called "Jev Decision Layer"

Use the official TypeSafe API.

Authentication:

The TypeSafe API exposes System One decisions.

Create these four tools:

jev_route_worker
jev_check_research
jev_review_completion
jev_guard_action

Do not let any tool execute the resulting action.

The plugin only returns decisions.

Add a short skill explaining when agents should use each tool.

Test every tool locally with one safe example before packaging it

TypeSafe's public API exposes a POST /v1/systemone endpoint with Choice, Score and Noul question types and Bearer-key authentication.

And Grok supports MCP servers as external tools; custom MCP connectors can expose API-backed tools to Grok through defined schemas and authentication.

So there is no magic glue here.

It is:

TypeSafe API → tiny decision plugin → Grok Bot tools.

This visual should come immediately after the prompt because it makes the integration feel much simpler than the code sounds.

This was the first design rule I stole from how decision systems should actually work:

Jev should only choose from things that exist right now.

If Engineering is unavailable, don't include Engineering.

If a project has no video, don't include Stills & Clips Desk.

If the next action legally requires me, include human_review.

The state might look like this:

Then Jev gets one question:

Which available worker should own the next unit of work?

Not:

“Plan my entire company.”

That distinction matters.

The surrounding system owns the workflow.

The model owns one fuzzy decision inside it.

TypeSafe's own workflow evals use the same general principle: break a policy into narrow intelligent questions and keep deterministic rules in code.

06. The first thing I would automate is routing

Let's use a real company task:

Research the biggest changes in AI agents this week, turn the findings into a long-form X article, create supporting visuals and prepare outbound for relevant AI companies. Do not publish or send anything.

Projects Manager starts with:

objective: Create a verified article + visuals + outbound package.

The first decision should be obvious:

Cooper / research first.

After research comes back, the state changes.

Now the available decision might be:

Cooper → gather more evidence Writing Bot → begin article SEO & AEO Desk → build search angle human_review → request clarification

Jev chooses again.

And again.

The interesting part isn't that an AI selected “Writing Bot.”

The interesting part is that routing becomes a visible, inspectable component instead of hidden reasoning inside a giant orchestration prompt.

If routing sucks, I can improve routing without touching the writer.
If writing sucks, I can improve the writer without touching routing.

That separation is the whole point.

Don't fabricate scores if you haven't run it. Replace the sample confidence with your real result before publishing.

07. Stop letting the researcher grade its own homework

This is where the architecture becomes genuinely useful.

Normally:

research agent finds a claim → research agent decides the claim is good enough → writer publishes it.

Same agent.

Same context.

Same mistake can survive the entire chain.

I would insert a gate.

Example claim:

“Company X launched Y yesterday.”

The research worker has to pass:

And our Jev tool can only return:

accept verify_more reject

If it returns verify_more, the claim goes back to research.

If it returns reject, it never reaches Writing Bot.

One important detail:

Jev is not the researcher.

It only sees whatever state and evidence you give it.

That is why the agent still needs actual source collection first.

This rule is much better than writing:

“Please double-check your facts.”

The system now has somewhere for a weak fact to go.

08. Never let an agent say “done” without proving it

The dumbest failure mode in long-running agent systems is also one of the simplest:

the agent says the task is finished because it feels finished.

So before Projects Manager can return a non-trivial project to me, I would force one final state:

My Projects Manager rule:

Before reporting a non-trivial objective as finished:

Restate the original objective.
List every required output.
Show where each output exists.
Show what was actually verified.
List every known gap.
Run jev_review_completion.

Never remove a known gap just to make the review pass.

The philosophy is tiny:

No proof, no done.

And there is another reason to keep this explicit.

Typed output does not mean factual correctness.

TypeSafe's own documentation makes that distinction: the interface can guarantee the output shape while the underlying judgment can still be wrong.

So Jev is a decision gate.

Not an oracle.

Big text:

NO PROOF NO DONE

Below:

objective → work → evidence → completion gate

Keep this image extremely simple. This is one of the most screenshotable ideas in the article.

09. Give autonomy levels instead of “full access”

This is where most “AI company” demos lose me.

They go from:

“look, the agent can research!”

to:

“now give it your email, card, CRM and production.”

No.

The Marketplace Bots themselves already show a better pattern.

Outbound Prospecting researches and drafts, but nothing sends without approval.

Haggle Bot investigates savings and drafts vendor counters, but does not spend, sign or send without you.

Recruiting Coordinator will not email a candidate without you.

Office Ops Desk does not send without you.

SpaceXAI's own automation guidance recommends approval for sending, purchasing, deleting, publishing and production changes.

So I would give the company five action levels:

LEVEL 0 — READ

Search, inspect, analyze.

Run automatically.

LEVEL 1 — PREPARE

Write drafts, create files, make recommendations.

Run automatically.

LEVEL 2 — REVERSIBLE WRITE

Update a draft, internal doc or non-critical record.

Jev can evaluate risk, but normal platform permissions still apply.

LEVEL 3 — EXTERNAL ACTION

Send email, contact a customer, publish, change a live account.

Human approval.

LEVEL 4 — MONEY / IRREVERSIBLE

Purchase, sign, delete, production changes, sensitive permission changes.

Human approval. Always.

Jev can help classify the action.

It should not magically erase the approval boundary.

That is how I would build “autonomous.”

Not “give every bot root.”

10. Don't automate anything until it works once

This part comes directly from SpaceXAI's own guidance and is probably the most important boring rule in the whole setup:

start with a one-time task → make it reliable → save the method as a skill → only then automate it.

So I wouldn't create 40 routines.

I'd start with five.

Morning Intelligence

Cooper

Every morning:

find material AI / competitor changes
attach sources
separate confirmed facts from weak signals
send important claims through the research gate
return only things worth the team's attention

Content Pipeline

Writing Bot + SEO & AEO Desk

When verified research is available:

find the strongest angle
prepare article brief
draft
run completion gate
stop before publishing

Outbound Prep

Outbound Prospecting

When a new campaign exists:

research matching companies
build context
draft first touches
stop at approval

Open Loops

GTM Loop Closer

Daily:

inspect outstanding promises and follow-ups
show evidence
prepare required updates
do not send

Company Review

Projects Manager

Once per day:

what finished
what is blocked
what is waiting for approval
what is currently running
what failed
what needs a human decision

Grok Bot routines can run in the background while the laptop is closed, and SpaceXAI recommends testing routines before enabling them because they may call connected tools and perform real work.

That is already enough to feel very different from ChatGPT with twelve tabs open.

11. Package the whole thing so someone else can clone it

This is why I like the Company-in-a-Box framing.

Once the system works, it should stop living in your head.

I would keep this package:

Grok Bot also supports sharing Bots as templates.

But there is an important catch:

a template is a blueprint, not an exact clone.

SpaceXAI says templates can package things like instructions, relevant memories, skills and supported plugins, while personal information, secrets and custom code/scripts are excluded. Non-standard MCP servers or code therefore need their own setup instructions.

That means the clean way to ship this publicly is:

Grok Bot templates for the workers + a small repo for the decision layer and setup.

Not a fake “one click installs my entire company including my API keys.”

Make the folder tree above into a clean editorial infographic.

Highlight only four pink folders:

/bots /jev /routines /tests

Caption:

The company should be portable, not trapped inside one chat.

12. Test it with a task that can actually fail

Do not test this with:

“write me a tweet.”

That proves nothing.

Give the company something that forces handoffs:

Find the 10 most important AI-agent developments from the last seven days. Verify every material claim. Turn the research into a long-form X Article, an SEO brief, a visual brief and a list of relevant companies with five personalized outbound drafts. Do not publish or send anything. Return the package only when every required output exists and has passed verification.

Now everything has a job.

Projects Manager decomposes the objective.

Cooper collects current information.

Jev decides whether the evidence is sufficient.

Writing Bot gets verified material instead of inventing its own facts.

SEO & AEO Desk creates the search angle.

Stills & Clips Desk handles usable media when footage exists.

Outbound Prospecting works from the final context.

Jev checks whether the project is actually complete.

And the external actions still stop at you.

That is an actual integration test.

What I would measure

I'm intentionally not putting fake benchmark numbers here.

Before publishing performance claims, I'd run the same set of tasks repeatedly and measure five things:

Routing accuracy

Did the right specialist receive the job?

Research escapes

How many material claims reached the writer without adequate evidence?

False completion

How often did the completion gate approve work with a missing deliverable?

Human interruptions

How many times did the company ask for me when it could have continued safely?

Recovery

When one worker failed, did the system retry intelligently or get stuck?

Every failure becomes a new test.

That is how the company improves.

Not by making the Projects Manager prompt 4,000 words longer.

I would turn this into the final big infographic rather than leave it as text in the published version.

The setup changed how I think about multi-agent systems

The hard part isn't building more agents.

The workers already exist.

The real problem is deciding what happens between them:

who goes next, what's good enough, when to retry, when to stop, and when a human should step in.

My mental model is simple:

Bots do the work. Projects Manager coordinates. Jev makes bounded decisions. Humans own irreversible actions.

That's Company-in-a-Box.

Not 12 chatbots.

A system that can actually move work forward without you routing every step.

Install the workers. Add the decision layer. Automate one proven loop at a time.

Follow @unicodef1wn so you don't lose the next useful AI setup.

AI Company-in-a-Box: Full 12-Step Roadmap to Build a Self-Managing Company with Grok Bot + Jev

Job breakdowns

01. Don't build the company from scratch

MANAGEMENT

RESEARCH / INTELLIGENCE

CONTENT

SALES

ENGINEERING

DESIGN

PEOPLE

FINANCE

OPERATIONS