Train Viktor so he becomes the company brain

Most teams treat Viktor like a chatbot: ask, get answer, forget. The teams that get more out of him map the jobs they want delegated, then give him clear role briefs for each one.

1. Start with a job map, not one job description.

   Viktor can do many jobs. List the outcomes you want delegated across marketing, sales, operations, finance, and personal work. Prioritize the first 3 to 5 jobs by value and repeatability.

2. Write one role brief per job.

   For each job, define the mission, responsibilities, what good looks like, cadence, sources, KPIs, and approval rules. Keep the roles separate so a correction to the finance analyst does not accidentally change the content writer.

3. Feed him the company basics once.

   Who is who, what the company sells, who the customers are, what words you use and never use. Say "remember this" and he stores it permanently. You should never have to explain your company twice.

4. Connect the tools where the truth lives.

   CRM, email, calendar, analytics, billing. An AI employee without integrations is a consultant without system access: smart but guessing. Connect the 3 to 5 tools your team argues about data from, first.

5. Correct him like you would correct a junior hire.

   When he gets something wrong, do not just fix it yourself. Tell him what was wrong and what the rule is. He writes it into his skills and the mistake does not repeat. Every correction is a permanent training investment.

6. Ask him what he is missing.

   After a week, ask: "based on everything you have seen, what context do you not have that would make you better at this job?" He will tell you. Fill the gaps.

Set up agents the right way

Viktor works where the conversation happens. In Slack and Microsoft Teams, your channel structure IS your delegation structure.

1. One channel per workstream, not one channel for everything.

   #marketing-viktor, #sales-ops, #finance-reporting. Each channel gets its own instructions, so Viktor behaves like a specialist in each: different tone, different rules, different default actions.

2. Give every working channel a 5 line instruction set.

   Who owns the channel, what Viktor should do there by default, what he must never do without sign off. Ask Viktor to set channel instructions and he does it himself.

3. DMs for personal work, channels for team work.

   Your inbox triage, your day planning, your drafts live in a DM. Anything the team should see lives in a channel. Viktor keeps DM content private by default.

4. Add Viktor to the channels where decisions happen.

   Even if you do not @ him yet. He reads context. When you finally ask "prep me for the Acme renewal", he already knows the whole history.

5. Set up a weekly 1 on 1.

   A recurring prompt: what did you ship this week, what did you notice, what do you recommend. This turns Viktor from reactive to proactive and it is where the compounding shows.

Crons that actually work

Crons are recurring jobs Viktor runs on a schedule: daily reports, inbox sweeps, pipeline checks, competitor monitoring. Done right they are the highest ROI feature in the product. Done wrong they are a credit furnace that posts noise nobody reads.

1. Run it manually 2 or 3 times before you schedule it.

   Ask Viktor to do the task live, correct the output until it is right, THEN say "run this every weekday at 8am". Never schedule a task you have not seen succeed.

2. Give every cron a "stay silent" condition.

   The best crons only speak when something changed or crossed a threshold. "Post only if a deal moved stages" beats "post the pipeline every day" after week two, because people stop reading unchanged reports.

3. One cron, one job.

   A cron that checks email AND updates the CRM AND posts a summary will fail in ways that are hard to debug. Three small crons beat one mega cron.

4. Tell the cron when it gets something wrong.

   Corrections to a cron persist the same way skills do. "The revenue number was wrong because you counted refunds, exclude them" fixes every future run.

5. Review your cron list monthly.

   Ask Viktor: "list all my active crons, when they last ran, and what each costs per month". Kill the ones nobody reads. Most workspaces have 1 or 2 zombie crons burning credits for a channel nobody opens.

Plan first, then execute

The most expensive Viktor mistake is letting him run a big fuzzy task with no checkpoint. The fix is one habit: for anything non trivial, ask for the plan before the work.

1. Say "make a plan first, do not execute yet".

   Viktor comes back with steps, what he will touch, and what he needs from you. You approve, adjust, or kill it in 30 seconds. This catches wrong assumptions before they cost hours and credits.

2. Use it for anything that touches the outside world.

   Emails to customers, CRM writes, published pages, payments. The pattern is: draft, review, send on approval. Viktor already asks for approval on sensitive actions, but saying "always show me before sending" makes it a standing rule.

3. For big projects, ask for a todo list he maintains.

   "Break this into steps, keep a running checklist, update me as you finish each one." You get visibility, he stays on track, and you can redirect mid flight instead of at the end.

4. Ask for the cheap version first.

   "Give me a one paragraph answer before you do the full analysis." Half the time the paragraph is enough and you saved 90% of the cost.

5. When the plan is approved, get out of the way.

   The point of planning up front is that execution then runs without you. Plan, approve, receive finished work.

A practical prompt architecture

For consequential work, build the request in four layers. Use only the layers that correct the failure mode you expect.

1. Outcome: what must be true at the end?

   Define the finish line before the method. Example: "The customer should receive a correct renewal recommendation with every number tied to a source."

2. Boundary: what is inside and outside scope?

   Prevent a small task from becoming an unnecessary refactor. Name what Viktor may change, what he must leave alone, and when he should stop to ask.

3. Evidence: how will the result be verified?

   Specify the source of truth and the proof required. Ask Viktor to inspect or run what the user will actually experience, not merely say that it should work.

4. Handoff: what should the final answer contain?

   Constrain the report to the outcome, relevant evidence, and any decision still required. Complex work does not need a complex handoff.

Follow this protocol.

1. PLAN: Define the perfect end state and the steps required.
2. EXECUTE: Carry out the plan completely without shortcuts.
3. VERIFY: Check every part against the original request and fix mismatches.
4. REPORT: State the outcome, evidence, and any decision required in one to three sentences.

Do not skip or compress a stage.

Credits without waste

Three parts: how credits work, how not to waste them, how to train a team on them. This is the number one question specialists get from clients, so it doubles as your cheat sheet.

Part 1: How credits actually work

1. Credits are one pool per workspace, not per seat.

   Adding teammates does not cost more credits. The right move is always to get the whole team in: usage is what you manage, not seats.

2. Cost follows thinking and doing.

   A quick answer is cheap. A deep research report with 50 sources is not. A cron that runs daily costs its price times 30 every month.

3. Model choice is the biggest single lever.

   Heavier models cost roughly 2 to 3x more per unit of work. Most routine work (summaries, triage, formatting, standard reports) is indistinguishable on a lighter model. Save the heavy model for judgment work: strategy, complex analysis, high stakes writing.

4. If you keep buying top ups, your plan is wrong.

   Top ups are for spikes. Three top ups in a month means you should move up a tier: it is cheaper and you stop thinking about it.

Part 2: The five waste patterns

1. Zombie crons.

   Scheduled jobs posting into channels nobody reads anymore. Fix: monthly cron review, kill anything without a reader. Usually the single biggest recovery.

2. Blowout threads.

   One giant vague request ("analyze everything and tell me what to do") that runs long and wide. Fix: scope the ask, request the short version first, use the plan first habit from Guide 04.

3. Retry loops.

   Asking again slightly differently because the first output missed. Three retries cost three runs. Fix: correct instead of retry. "Same output but exclude refunds and shorten to 5 bullets" is one cheap run and it teaches him permanently.

4. Heavy models on routine jobs.

   A daily summary cron running on the most expensive model. Fix: audit which crons run on which model, downgrade the routine ones. Often 1 or 2 crons account for most of the heavy model burn.

5. Re-teaching context.

   Explaining your company, your format, your rules in every thread. Fix: say "remember this as a rule" once. Context that lives in skills is free forever; context re-explained in every message is paid every time.

Part 3: Training the team (norms beat limits)

1. "Correct, don't retry."

   Make it a team phrase. It is the difference between paying once and paying three times for the same output, and only one of them makes Viktor better.

2. Delegate outcomes, not keystrokes.

   "Get me a meeting with Acme's CFO next week" beats 15 separate micro asks. Bigger, well scoped delegations are more credit efficient than chat style usage.

3. Every recurring output needs a named reader.

   Before anyone schedules a cron: who reads this, and what do they do with it? No answer, no cron.

4. Make cost visible, not policed.

   A monthly "ask Viktor where our credits went" review in a team channel. When people see that one zombie cron cost more than all their DMs combined, behavior fixes itself.

Skills: build them to a real standard

A skill is a portable capability Viktor loads when relevant. Build it to the Anthropic Agent Skills standard so it triggers reliably, uses context efficiently, and can carry instructions, references, assets, and deterministic scripts.

1. Use Anthropic's official skill-creator.

   Do not treat a long prompt or an automatically saved note as a finished skill. Start with Anthropic's skill-creator, interview the user, and produce an Agent Skills compatible folder with a valid SKILL.md.

2. Get the trigger metadata right.

   The YAML frontmatter needs a clear name and a description that says both what the skill does and when to use it. This determines whether Viktor loads the skill, so vague descriptions lead to under-triggering.

3. Use progressive disclosure.

   Keep SKILL.md focused on the core workflow. Put detailed documentation in references, reusable templates in assets, and deterministic operations in scripts. Viktor loads each layer only when needed.

4. Build from a workflow that already succeeded.

   Complete the task manually, correct it, then encode the proven method. Include sources, quality criteria, edge cases, approval points, and failure handling.

5. Test triggering and output before installing it.

   Run realistic positive and negative prompts. Confirm it loads when it should, stays out when it should not, follows the workflow, and produces the expected result.

6. Maintain it like software.

   Name an owner, keep examples current, version important skills, and retest after material edits.

Five starter skill briefs

These are discovery briefs, not finished skills. Use them as inputs to Anthropic's official skill-creator, then review, test, and package the Agent Skills compatible folder before installing it.

1. Company context

Company: [name]
What we sell: [products or services]
Ideal customers: [segments and buyers]
Positioning: [why customers choose us]
Approved and banned terms: [list]
Authoritative sources: [docs and systems]
Ask for missing context before building the skill.

2. One role in the job map

Role: [role name]
Mission: [outcome]
Responsibilities: [3 to 7]
Success metrics: [KPIs]
Sources and tools: [systems]
Approval rules: [what needs sign off]
Escalate when: [exceptions]
Keep this role separate from Viktor's other jobs.

3. Writing voice

Person or brand: [name]
Audience: [reader]
Voice: [traits]
Formatting rules: [rules]
Use and avoid: [terms]
Approved samples: [examples]
Test against one new draft before installing.

4. Recurring workflow

Workflow: [name]
Trigger and outcome: [start and definition of done]
Inputs and source of truth: [data]
Proven steps and decisions: [method]
Approval checkpoint: [owner]
Output and destination: [format]
Failure handling: [when to stop]
Test manually before scheduling.

5. Standing correction

What was wrong: [issue]
Correct rule: [expected behavior]
Scope and exception: [boundaries]
Correct example: [example]
Update the relevant standard skill, summarize the diff, and rerun its tests.

Skill, channel instructions, or cron?

Most implementation problems are good instructions stored in the wrong place. Use this model to build a system Viktor can maintain.

1. Put the method in a skill.

   Define sources, judgment, output quality, and escalation rules once.

2. Put local behavior in channel instructions.

   Define who to tag, the local tone, and when to stay silent.

3. Put timing in the cron.

   Reference the skill instead of duplicating its method in the schedule.

4. Correct the right layer.

   Wrong analysis: update the skill. Wrong room behavior: update channel instructions. Wrong timing: update the cron.