What a private AI team actually does

"AI team" is an easy phrase to cheapen. Most of the time it means one person, one chat box, and a document of system prompts they paste in rotation. That can be useful. It is not a team. A team splits the work, keeps the split from becoming a second job, and brings the result back to one place.

T-FORCE is built around that narrower claim. You talk to a Manager. The Manager plans, answers what it can alone, and hires a specialist when the job needs one. You do not keep a row of chats and ferry paragraphs between them.

The transcript is doing too many jobs

A single conversation is a good place to ask a question. It is a bad place to be the planner, the researcher, the writer, the operator, and the archive at once. Those jobs interrupt each other. The research dump pushes the brief out of view. The draft starts arguing with the notes. The next morning you scroll, looking for the sentence where you decided what "done" meant.

People paper over this by opening more chats. One for research, one for the draft, one for the code. The bookkeeping then moves outside the model. You become the integration layer, copying the useful part and hoping you copied the current part. The model did not get slower. The work of being the manager did not go away. It landed on you.

A private AI team is an attempt to put that job back in the software, without turning the software into another inbox you have to patrol.

You hire by describing the work

The Manager is the only person you have to address. That is a product decision, not a personality. If you had to pick Research or Writer before you knew which one the job needed, you would be doing the planning yourself and then pretending an agent had done it.

So the first move is a plan. The Manager answers what is already a direct question, breaks the rest into steps, and hands a step to a specialist when the step is no longer something it should do inline. The hire is the interesting moment. It is where a vague request becomes a role with a task, and where you can see who was asked to do it.

The roles are ordinary on purpose.

• Research looks things up and cites sources.
• Analyst works through metrics.
• Developer reads repositories and writes code.
• Writer drafts the note, the email, or the proposal.
• Data handles tables.
• QA checks the work.
• Operations talks to Gmail, Drive, Slack, and GitHub.
• Content makes stills, video, speech, and sound.

None of that is a new capability the model did not already approximate. The point of naming them is that a plan can say who does the step, and the result can say who did it. An unnamed blob of "the AI" cannot be staffed, checked, or replaced in one role without restarting the whole conversation.

A template is not a headcount

Most of those roles start as templates. They are not sitting in the sidebar, idle, waiting to be talked to. Content is the exception. It is there from the beginning, next to the Manager, because making a still or a clip is a standing capability rather than a hire you discover halfway through a memo.

When the work needs a second researcher, for a different subject, the Manager can hire another one from the same template. That is the part worth sitting with. Sharing a template does not mean sharing a mind. Each agent keeps its own memory. The project keeps a shared one. Two researchers can know the same method and still not be carrying each other's notes.

This is how the roster stays small. A team that lists every possible specialist on day one is a menu. A team that hires from a template when the plan names the need is closer to staffing. You are not maintaining twelve conversations you opened just in case.

There is a cost to that restraint. You cannot glance at a full org chart and see every role that might someday matter. You see the Manager, Content, and whoever the current work has actually hired. If you wanted a dashboard of unused agents, this will feel empty. The emptiness is the design. Unused agents are how a roster turns back into a folder of prompts.

The result has to come home

Specialist work that stays in a side panel recreates the problem the Manager was supposed to solve. You would still be the person walking between rooms, asking what happened. The Manager's last job in a step is to bring the result back in plain language, into the conversation you were already having.

That return path is also where judgment stays with you. The team can draft, look up, and propose. Whether the draft is the one you send is a later question, and it is a different mechanism from hiring. Hiring gets the work done. Approval decides what the work is allowed to change. Mixing those up is how a product becomes either helpless or reckless: either every keystroke waits, or the send happens because the draft looked finished.

What "private" is doing in the name

Private, here, is a statement about where the project lives. T-FORCE is a Windows app. Projects, chats, and memory sit in a local database on that PC. Keys for models and integrations go into the operating system keychain, and the window does not show them back to you. There is no shared cloud workspace holding your documents, and installing the app does not create an account.

It is not a statement that a model call never leaves the building. If you choose OpenAI, Anthropic, DeepSeek, Moonshot, or the built-in T-FORCE provider, that request goes to the provider you picked. A local Ollama model is the case where the inference can stay on the machine. The files still stay where you installed the app. Those are different sentences, and they should stay different.

The shape of the work is the claim this essay is willing to make. One Manager. Specialists when the plan needs them, from templates rather than from a permanent bench. The result back in the same conversation. The record on your computer. Everything past that — what is remembered, what is allowed to happen, and what a provider still sees — is a separate argument, because it fails for different reasons.