AI Team Members

AI team members are named workers inside your workspace. Each one has a job, a set of instructions, and a set of tools it is allowed to use.

If you only ever wanted to ask one assistant a quick question, you would not need this model. Worka uses AI team members because real work quickly becomes too broad for one generic assistant. Planning, research, tool use, approvals, follow-up, review, and release are different jobs. When one role tries to do all of them, the system becomes hard to trust and hard to control.

What an AI team member is

Think of an AI team member as a role in your workspace.

A good role has five parts:

• a clear name
• a clear responsibility
• instructions about how it should behave
• a list of packs and tools it may use
• rules about when it should hand work to someone else or wait for approval

Examples of useful roles include:

• an intake coordinator that reads incoming requests and turns them into structured work
• a researcher that gathers information and prepares a recommendation
• a pack developer that creates or extends a missing capability
• a reviewer that checks the result before release
• a follow-up agent that sends updates to a customer or team

The point is not to create lots of personalities. The point is to separate jobs cleanly enough that you can understand who is doing what.

Why you would create more than one

Create more than one AI team member when the work has distinct phases or responsibilities.

For example:

• one role receives inbound messages
• another role decides what kind of work needs to happen
• another role performs the task
• another role checks the result before it is shared or published

This matters because each role can then have tighter instructions and tighter access.

If a role only needs to classify incoming requests, it should not also have permission to publish a release. If a role only needs to prepare a draft reply, it should not also have permission to send the final message. Breaking work into named roles makes the system safer and easier to reason about.

How to create an AI team member

Create AI team members inside the workspace where the work will happen.

The basic process is:

1. add a new AI team member
2. give it a name that describes the job
3. write a short description of what it is responsible for
4. choose the packs and tools it may use
5. choose what requires approval
6. decide how work should move on after it finishes
7. test it with one realistic task

The most common mistake is making the role too vague. Names like assistant, worker, or automation bot tell you very little. Names like Intake Coordinator, Release Reviewer, or Customer Follow-up tell you exactly what the role is supposed to do.

How to control what an AI team member does

You control an AI team member in three main ways.

First, you control its instructions. These should describe the job, the limits, the style of output you want, and the situations where it should stop and ask for help.

Second, you control its access. If a role does not need browser control, do not give it browser control. If it only needs one pack, do not expose five. Most mistakes become less likely when each role has a smaller tool surface.

Third, you control its hand-offs. You decide whether the role should finish the whole task itself, pass work to another role, call a tool, or wait for a human approval step.

How to control what packs and tools it can use

Each AI team member should only see the packs and tools that fit its job.

For example:

• an intake role may only need communication tools and classification tools
• a researcher may need search, retrieval, and note-taking tools
• a release role may need publication tools and approval flows
• a browser automation role may need browser control but nothing that can publish changes elsewhere

As a rule, start narrow. Give a role the smallest useful set of packs and tools, then expand only when the work clearly requires it.

This is also how you keep the workspace legible. When a role has access to everything, you no longer know whether it succeeded because its design was good or because it happened to have too much power.

How to control behaviour beyond tool access

Tool access is only one part of control.

You should also decide:

• whether the role may act automatically or must wait for approval at certain points
• whether it is allowed to create follow-up work on its own
• how much context it receives from earlier steps
• what information it is allowed to send to another AI team member
• what counts as success for the role

For example, you might let a triage role classify every incoming request automatically, but require approval before a response is sent to a customer or before a new integration is attached to the workspace.

How hand-offs work

When one AI team member finishes its part of the job, Worka needs to decide what happens next.

There are two main ways to do that.

Let the AI decide

In the flexible approach, the current AI team member decides what should happen next based on the task, its instructions, and the data it has gathered.

This is useful when the work is varied and you want the system to adapt.

The trade-off is that the AI can make the wrong call. It may forget to pass along something important, choose the wrong next role, or stop when the work should continue.

Use hooks

In the mechanical approach, you define hooks that run at specific moments in the workflow.

A hook can fire:

• when an AI team member is invoked
• when a tool returns a result
• when a step is about to complete

The hook then decides what happens next using explicit rules. It can inject context, create a follow-up tool step, hand work to another AI team member, add a dependency, or delay completion until another condition is met.

Use this approach when you need consistency more than flexibility.

For a full explanation, read Hooks and Hand-Offs.

Example: incoming WhatsApp message

Imagine a customer sends a WhatsApp message saying:

“The boiler is leaking again. Can someone come tomorrow morning?”

One good setup would be:

• Message Intake reads the message and extracts the problem, urgency, and preferred time
• Maintenance Coordinator checks available engineers, location, and policy
• Customer Reply sends the confirmed appointment or asks a follow-up question

You could let the intake role decide what to pass along. That is quick and flexible.

Or you could use a hook that says:

• if the incoming message contains a fault report and a requested time
• and the extraction step succeeded
• automatically hand the structured data to Maintenance Coordinator

That second approach is less flexible, but it is predictable. If the data exists, the hand-off happens.

How Worka executes work behind the scenes

When you ask Worka to do something, it creates work that is broken down into tasks and steps.

A task is the larger piece of work you care about, such as:

• build a new workspace
• answer an incoming message
• prepare a release
• investigate an issue

A step is one action inside that task. A step might:

• invoke an AI team member
• call a tool
• wait for approval
• hand work to another role
• publish a result into a view

As steps complete, Worka can create more steps. That chain can keep expanding for as long as more work is needed. The process only stops when the job is finished, blocked by policy, or waiting for more input.

This is why Worka feels different from a normal chat product. The system is not just generating a reply. It is executing a sequence of visible work on your behalf.

What good AI team member design looks like

A good design is simple enough that you can explain it to another person.

You should be able to answer questions like:

• what is this role for
• what tools can it use
• what can it do without approval
• when does it hand work to someone else
• what should happen if it gets stuck

If you cannot answer those clearly, the role is too vague. Tightening the role almost always improves the workspace.