How we onboarded a team to Codex
What a practical Codex onboarding looks like when the goal is reusable team workflows, not one-off prompts. Based on a real workshop covering workflow mapping, agent architecture, skills and shared setup.
Key takeaways
- Codex onboarding works best when it starts with workflow mapping, not prompt demos.
- Teams need shared knowledge, connectors, skills and agents so useful work can be repeated.
- GitHub syncing matters because AI workflows need a source of truth, review and version control.
The workshop was not about teaching prompts
The first mistake with team AI onboarding is treating it like software training. Show the interface, explain the buttons, run a few examples, and hope people become more productive after lunch.
That is not where the value is. The useful work starts before Codex opens. You have to understand what the team already repeats, where judgment sits, what information they trust and where the review step belongs.
In this workshop, the goal was to move from individual AI habits to shared workflows the team could reuse. Less copy-paste prompting. More approved knowledge, repeatable skills and clear human review.
Start with workflow mapping
We started with process mapping because Codex needs a job, not a vibe. A useful workflow has a trigger, inputs, expected output, reviewer and a clear risk if the output is wrong.
For an account manager, that might be checking a client brief before quoting. For digital, it might be preparing an SEO opportunity check. For leadership, it might be turning meeting notes into decisions and next steps.
This matters because the same model can behave like a drafting assistant, checklist reviewer, researcher or technical advisor depending on how the workflow is framed. If the workflow is vague, the agent becomes vague too.
Work out where AI belongs
Not every step should be automated. Some parts need judgment, relationship context or commercial caution. The workshop separated what Codex may do, what it must ask before doing and what it should never decide alone.
That gives people permission to use the tool without pretending it is magic. Codex can draft emails, summarise meetings, analyse briefs, prepare checklists and suggest next steps. It should ask before sending messages, confirming scope, quoting prices or changing shared files.
Those boundaries make adoption easier. People do not need to guess whether they are allowed to use AI. They know which parts are safe to delegate and which parts still need review.
Explain what Codex is and what it is not
Codex is not just another chat window. Used properly, it becomes a working layer that can read project files, follow shared instructions, call tools and run repeatable skills.
It is also not a replacement for the person doing the work. The person still owns context, judgment and approval. Codex helps prepare the draft, check the brief, inspect the data or structure the next action.
That distinction helped the team. The mental model moved from “ask AI a question” to “give Codex a known workflow and let it run the agreed steps.”
Use four building blocks
The workshop used four simple building blocks: knowledge, connectors, skills and agents.
Knowledge is what Codex should know. Agency context, service boundaries, quote standards, communication principles and role expectations.
Connectors are what Codex can access. Gmail, Drive, Calendar, analytics, search tools, quote data and other systems, depending on permissions.
Skills are how Codex should do repeatable work. Brief readiness checks, quote QA, client email drafting, SEO opportunity checks and similar workflows.
Agents are who Codex should act like for a task. Account manager, digital lead, copywriter, researcher, partner or another role with a clear operating style.
Onboarding is personal before it becomes shared
The shared pack gives the team a base. It holds the agency context, role presets, skills, connector guidance and setup instructions. But each person still needs a personal layer.
That layer captures how they work, how they like messages written, what Codex can do without asking, what needs approval and which repeated workflows they want help with first.
This is where adoption becomes real. A generic assistant is easy to ignore. An assistant that understands your role, your approval boundaries and your weekly handoffs is much harder to dismiss.
Custom skills turn good habits into team assets
The strongest part of the setup was not a single agent. It was the skill layer. A skill is a documented way to perform a recurring task so the same reasoning does not have to be rebuilt every time.
If someone keeps asking Codex to check briefs, draft handoff emails or review quote scope, that pattern should become a skill. The skill captures the checklist, tone, order of operations, escalation points and expected output.
That is how one person's improvement becomes a team asset. The workflow stops living in a private prompt history and starts living in a shared pack other people can use.
GitHub syncing is not a technical extra
The shared agent pack needs version control. Without it, every person slowly drifts into a different setup. Skills change, instructions get copied by hand and nobody knows which version is current.
GitHub syncing gives the team a source of truth. Updates can be reviewed, pulled and reused. New skills can be added without sending loose files around Slack or email.
That sounds like technical plumbing, but it is adoption infrastructure. If the team is going to rely on AI workflows, those workflows need the same care as any other operational system.