# Put Your AI Teammate to Work

Canonical URL: https://socra.com/guides/first-ai-teammate

Start with work you want to take on: a launch to coordinate, a decision to research, a customer journey to improve. Give one teammate responsibility for a clear result, the knowledge and access to pursue it, and a person who can judge the work. Then build on what the first result teaches you.

A CoAgent is an AI teammate with its own identity and cloud computer. A role gives its work continuity. An assignment gives it something specific to do next. A scheduled Task brings it back when future work is due. These are three different decisions—and getting them right is how a useful first answer becomes an ongoing contribution.

## Make the Role Yours

Choose a starting point, replace the brackets and edit the brief to fit your team. These are proposed assignments, not customer results. Copy the finished brief into your teammate’s conversation in Socra HQ.

### Launch coordinator

Keep a launch ready for a human go/no-go decision.

```text
# Launch coordinator

## Responsibility
Keep our launch brief aligned with confirmed decisions. Help me see what is ready, what changed and what still needs an owner.

## First assignment
Compare [launch brief] with [release plan]. Update the draft with confirmed dates. Link each change to its source. Return a readiness summary: ready, unresolved, and decisions I need to make.

## Knowledge and access
Use [approved product facts] and [launch decisions] as shared knowledge. Read the release plan; edit the launch draft; post in [launch channel]. If dates conflict, identify both sources and ask which governs. Do not change the release plan or send customer announcements.

## What good looks like
Every changed date has a source. Each unresolved item names the missing fact or owner. I can make the go/no-go decision from the summary and inspect the supporting draft.

## Handoff
Send [reviewer] the updated draft, the change list and the source links. Ask them to check the changed facts. Keep the work open until they accept it or describe what needs correction.

## Follow-through
After I accept the first result, propose a weekly Task with a time and timezone for my agreement. Confirm that it exists and its next run. Report material changes and decisions needed; do not repeat an unchanged status update.

## Limits
Reviewer: [name]
First result due: [date, time, timezone]
Running-time budget: [limit]
Stop and ask if the source is inaccessible, a decision is missing or the budget is reached.

## Learn from the review
Save reusable corrections with their reason in our shared knowledge. Apply them to the next brief and show how the result changed. Keep one-off exceptions with this launch.
```

### Research analyst

Turn an open question into a decision you can make.

```text
# Research analyst

## Responsibility
Maintain the evidence behind [decision]. Help me understand the tradeoffs and what would change the recommendation.

## First assignment
Compare three options for [specific need] against [criteria and budget]. Start with primary sources. Return a short recommendation, a comparison table and the questions the evidence does not answer.

## Knowledge and access
Read [requirements], [previous decisions] and the relevant public sources. Save the report in [shared folder]. Separate source facts, your inference and unknowns. Record when you checked changeable facts such as prices and availability. Do not contact vendors, create accounts or buy anything.

## What good looks like
Each important claim links to its source. The comparison uses the same criteria for every option. The recommendation explains the tradeoff and identifies any missing fact that could reverse it. State when none of the options meets the requirements.

## Handoff
Send [decision owner] the recommendation and evidence. Ask for a decision or a specific next question. Do not treat a plausible report as an approved choice.

## Follow-through
After review, propose a dated follow-up only for facts likely to change before the decision. Confirm the Task and next run. Notify me when a changed fact changes the recommendation.

## Limits
Reviewer: [name]
First result due: [date, time, timezone]
Running-time budget: [limit]
Stop and ask when a required source cannot be checked, criteria conflict or the budget is reached.

## Learn from the review
Save the criteria we actually used and the reason for the decision. Retrieve them for the next comparison; recheck facts that may have changed.
```

### Product reviewer

Find the moment a customer gets stuck—and verify the repair.

```text
# Product reviewer

## Responsibility
Review [customer journey] from the customer's point of view. Follow a concrete problem through to a result that works on the released product.

## First assignment
Try [one journey] on [supported device or browser]. Record the first point where the person cannot complete their goal or understand the next step. Describe what you did, what happened, what should happen and the evidence another person needs to reproduce it.

## Knowledge and access
Read [product intent] and [known issues]. Use [approved test environment and test identity]. Do not use customer data, make purchases, change permissions or modify production. If the required device or access is unavailable, report that limit and inspect what you can.

## What good looks like
The finding is reproducible and explains its effect on the customer. Check for an existing Issue before creating one. Separate the observed problem from an unproven explanation of its cause.

## Handoff
Give [implementation owner] the reproduction and a clear acceptance check. When they report delivery, repeat the original steps against the released version. Check that the repair preserves the surrounding journey. Accept it only when the original problem is resolved.

## Follow-through
Keep unresolved work in its owning Issue. If delivery is pending, identify the next owner and the event or scheduled time that will trigger your recheck. Do not repeatedly run the same check without a changed condition.

## Limits
Reviewer or decision owner: [name]
First result due: [date, time, timezone]
Running-time budget: [limit]
Stop and ask if the test would affect a customer, requires unavailable access or reaches the budget.

## Learn from the review
Save a reusable inspection lesson only after the evidence supports it. On the next relevant review, apply that lesson and check whether it catches the same class of problem.
```

## Choose Work Worth Owning

Start with an outcome you would value this week. “Own marketing” leaves too much undecided. “Keep our launch brief accurate and tell me what prevents launch” gives the role a purpose and a result you can inspect.

| Role | First useful result | Responsibility after review |
| --- | --- | --- |
| Launch coordinator | A sourced readiness brief with unresolved decisions. | Keep the brief aligned with confirmed changes. |
| Research analyst | A recommendation against your criteria, with sources and unknowns. | Revisit the recommendation when a material fact changes. |
| Product reviewer | One reproducible customer problem and an acceptance check. | Follow the repair through to verification on the released product. |

Choose a job whose facts the teammate can reach and whose result someone on your team can judge. Keep the first version small enough to review. The role briefs above are proposed assignments, not customer results. They are starting points: replace their bracketed fields and remove responsibilities you do not need.

## Show What a Good Result Looks Like

Give the teammate the actual source, the destination for the work and your acceptance criteria. An example of a good past result helps more than “be excellent.” Name the decision the result should make easier.

For a launch coordinator, a useful first message is:

> Compare our launch brief with the release plan. Update confirmed dates in the draft and link each change to its source. Return what is ready, what is unresolved, and the decisions I need to make. If sources disagree, show me the disagreement. Do not send the customer announcement.

Ask it to identify missing access or a decision that prevents useful work. It can advance independent parts while a question is open. Repeating the same unanswered question or unchanged check is not progress.

In [Socra HQ](https://hq.socra.com/), use Agents to hire and manage the teammate, Channels to discuss its assignment, and Drive for shared files. The [setup guide](https://workspace.socra.com/docs/agents/get-started) covers the supported steps to the first conversation. Keep the brief with the result so another person can understand what was asked.

## Give It the Knowledge and Access Its Role Needs

Share the decisions that would change its answer: which release date is approved, which customer the offer serves, why a requirement exists. Put reusable team knowledge in [Cortex](/cortex), where Modules cover subjects and Dependencies connect prerequisite knowledge. A Flash retrieves a Module and its prerequisites before work starts.

A saved rule helps only when it is retrieved, applied and checked. Stored guidance also does not prove that today’s price, deadline or implementation is still correct. Ask for current source checks where facts can change.

Give the teammate access under its own identity. For the launch job, that might mean reading the release plan, editing the launch draft and participating in the launch channel. It does not require access to payroll or permission to send customer email. A written instruction states intent; permissions enforce what the identity can reach. Use both.

The [identity and access guide](https://workspace.socra.com/docs/agents/concepts/identity-and-access) and [access setup](https://workspace.socra.com/docs/agents/guides/access-and-credentials) describe the supported boundaries. External tools still depend on their supported authentication and permissions. Personal working notes and files are explained in [context and memory](https://workspace.socra.com/docs/agents/concepts/context-and-memory).

## Make the Handoff Part of the Job

A second teammate becomes useful when there is a distinct responsibility and a clear handoff. One can investigate and implement; another can test whether the original problem is actually resolved. A person retains the decisions that matter.

**A recorded example from Socra’s own team, November 9, 2026:**

1. **The reviewer found a specific problem.** Four public pages used an older product description in their shared-link metadata. The finding named the affected pages and how to check the repair.
2. **Marketing traced and repaired the source.** A shared preview setting was overriding page-specific descriptions. Marketing reported the change, deployment and live checks; a related product-title correction followed.
3. **The reviewer checked the released result.** The descriptions and new title passed. The review also caught that the deployment included another owner’s wording change, so “only the heading changed” did not describe the whole release.
4. **Marketing corrected the account of the work.** The delivery report was amended to distinguish its own commit from everything the deployment actually served.

[Read the recorded handoff](/evidence/coagents/review-handoff-2026-11-09.txt). This is one internal example, based on delivery and receiving-review records. It is not a customer case study, a speed benchmark or proof that every assignment succeeds. External social-preview caches and the full signed-in journey were outside that review.

The pattern you can use is simple: the sender names the result and acceptance check; the recipient checks the result against the original need; unresolved differences return to the same work record. “I finished” begins the handoff. “This resolves the problem” ends it.

## Arrange the Next Piece of Work

A role description does not create a schedule. Incoming work and scheduled [Tasks](/tasks) can wake a sleeping teammate. Ask it to arrange the follow-through, then check the saved schedule and next run. A manually paused teammate stays paused until resumed.

For the launch coordinator:

> After I approve this first brief, propose a Monday review at 9 a.m. in our timezone. Once we agree, create the Task and confirm its next run. Compare the brief with current decisions. Notify me when a confirmed date changes or a decision needs me. Keep unchanged checks in the work record.

Decide what should happen when the work is blocked. Name the missing input, the person who can supply it, and the event or time that warrants another check. Keep useful independent work moving. Avoid repeated checks with no changed condition.

A teammate’s persistent home survives ordinary sleep, restarts and runtime upgrades; a running process does not have the same guarantee. Ask it to save the working state and next step before a long job is interrupted.

## Turn Feedback Into Better Next Work

Give feedback against the result you asked for. “The launch date must come from the approved plan, not the discussion thread” identifies a reusable decision and its reason. “Try harder” does not.

Ask the teammate to preserve the reusable lesson in the right shared knowledge, keep a one-time exception with its assignment, and apply the lesson to the next relevant job. Then check that next result. Writing a memory is not evidence of improved performance.

Keep a short review record:

| Check | Evidence to keep |
| --- | --- |
| Useful result | The actual report, draft or released change, compared with the brief. |
| Accuracy | Sources you checked and corrections required. |
| Scope | What it changed and whether those changes were permitted. |
| Effort | Your briefing, review and correction time. |
| Cost | Recorded running time and charges for the assignment. |
| Decision | Accept, revise or stop—and why. |

If a result is weak, locate the cause before adding another teammate: unclear expectations, missing facts, unavailable access or execution. More roles also create more handoffs. Expand the team when there is another real responsibility, not to compensate for an undefined first one.

## Know What the Work Costs

Socra HQ costs $20 per human seat per month, including $20 per seat in shared usage credit. Each managed teammate costs $3 per month plus $1 per running hour. Both teammate charges use the same included credit. An eligible ChatGPT subscription with Codex or Claude subscription with Claude Code is required separately; provider prices and usage limits apply.

These full-month examples use total billable running hours across all listed teammates. They assume no other HQ usage, no taxes or provider charges, and additional running usage enabled wherever needed:

| Human seats | AI teammates | Total running hours | Teammate charges | Included credit | Socra HQ total |
| --- | --- | --- | --- | --- | --- |
| 1 | 1 | 10 | $13 | $20 | $20 |
| 1 | 1 | 17 | $20 | $20 | $20 |
| 1 | 2 | 30 | $36 | $20 | $36 |

Running time is wake-to-sleep time, including time awake while waiting. Each session rounds up to a whole minute, with a one-minute minimum. This is not a price per accepted result.

Additional running usage is off by default. Running pauses when available credit is exhausted unless an Account owner enables additional usage. The monthly teammate charge continues while the teammate exists and can exceed included credit. Unused credit does not roll over. Teammates on the same AI connection share the provider subscription’s allowance while keeping separate Socra identities and saved work. Use the [pricing calculator](/pricing) for your team.

## Start With One Role. Keep What Works.

Choose a brief above, replace the brackets and give the teammate one result to pursue. Review that result, agree on follow-through, and preserve what you learn. Your next role should have a clear job and a useful handoff to the team already in place.

[Explore Agents](/agents), check the [subscription requirements](https://workspace.socra.com/docs/admin/agents/connect-an-ai-subscription#before-you-start), or [download the blank assignment template](/resources/first-ai-teammate-brief.txt).