1 Summary
This document describes where Hostify is going as a company, in plain words, and what that direction asks of Operations. Nothing in it is a sales text. Where a thing is still a draft or a plan, the text says so.
1.1 Who it is for
The Chief Operating Officer first: the plan gives that role the ownership of how the company works, across every function, and a chapter of its own describes it. Then the people who run the day-to-day operations and own incidents, deploys, service levels and the handovers between support, engineering and the business functions. It assumes no technical background. Anyone in the company may read it; the chapter on development is there so that Operations can see what a mature process looks like, not because the reader is expected to work in the code. It was written by the CTO's office and is meant to be read in one sitting.
The direction has two parts, and they depend on each other.
One knowledge base. Everything the company knows about how it works goes into one place: the engineering wiki in the HostifyRoot workspace. Not only code documentation. Processes, roles, who decides what, the decisions that were taken and why, the open problems, the rules of each function. Today this knowledge sits in people's heads, in Slack threads, in Intercom macros, in the Help Center, in a dozen repositories and in the memory of whoever has been here longest. The goal is that a new colleague, or a program, can find the answer to "how do we do X here" by reading one page, and that the page is the same for everyone.
One shape for every process, with an agent in each. Every function of the company (support, operations, development, QA, product, sales, HR, accounting) gets its processes written down in the same shape: purpose, roles, steps, what the agent does, inputs and outputs, service levels, the ways it can fail. Once a process is written once and agreed, a software agent is given a part in it. Not to replace the person who owns the process, but to do the repeatable parts under rules the person set: read the evidence, draft the answer, check the preconditions, write the record. The person decides; the agent prepares and records.
The order matters: first the knowledge base and the written process, then the agent. Automating five versions of the same process produces five automated problems. The company's rule for this is written as "consolidation before automation".
1.2 What exists already
- The HostifyRoot workspace, a private repository that every employee works in through the same tools, with the wiki, the process pages, the role pages and the command-line tools.
- Process pages for every function listed above. Most are drafts waiting for their owner to read and confirm them. The engineering ones (how a working session starts and ends, how a new person is onboarded) are active and used every day.
- Agents already at work in support and in the product: David takes every Intercom conversation, Dexter investigates read-only in the production data, Vicky answers product questions from the Help Center. Guest messaging and reporting in the product have their own agents. These were built one by one; the plan brings them under one set of rules and one memory.
- A delegation policy that says which decisions an agent may take alone, which it must record, and which it may never take without a person.
1.3 What this asks of the COO
The plan has a technical owner, the CTO, and a product owner, the CEO. It has no owner yet for the processes themselves as one whole: which exist, who owns each, how they are measured, where two teams do the same work twice. The CTO proposes that this is the COO's, and the chapter on the role says what that means. The asks are listed in the last chapter and summarised in the recommendations table: take the process map as the working document, confirm the operations processes, name an owner for every process that has none, set the service levels that are marked "not defined", and decide with the CTO which agent mode each process starts in. None of this needs a technical background. It needs the authority to decide across functions and knowledge of how the work is actually done today.
1.4 Sources
Every statement here traces to a page in the wiki, named in the chapter that uses it: the mission page (wiki/company/mission-agentic-first.md), the process pages (wiki/processes/), the organisation page (wiki/people-teams/org-structure.md), the delegation policy and the working rules (wiki/conventions/company/). The wiki is internal; this document carries nothing marked confidential.
2 Where we start from
An honest picture of today, because the plan is a response to it.
2.1 Knowledge is spread out
The way Hostify works is known, but it is known in pieces, each in a different place:
| Where the knowledge sits today | What it holds | Who can read it |
|---|---|---|
| People's heads | How things are really done, what to avoid, who to ask | Whoever is in the room |
| Slack threads and direct messages | Decisions, incident timelines, agreements | Whoever was in the thread; hard to find later |
| Intercom and the Help Center | How the product is explained to customers | Support, and customers |
| Repositories (code, READMEs, wiki pages per repository) | How each system is built and deployed | Engineers who know which repository to open |
| Asana, spreadsheets, documents in shared drives | Plans, tasks, lists | Varies by team |
| The engineers who built each system | Why it was built that way | Only while they are here |
None of these places is wrong. The problem is that they do not agree with each other, nobody owns the whole, and a question answered in one of them is answered again next week in another. When a person leaves, their part of the picture leaves with them.
2.2 Processes differ by team and by person
The same kind of work is done in several ways. A production change goes out through a pipeline in one system and by hand from a workstation in another. A support answer comes from the Help Center in one case and from memory in another. An incident is handled well by the people who happened to be on, and the next one starts from zero because nothing was written down. The process pages in the wiki list these cases under "failure modes", and they are the reason each page exists.
2.3 Agents exist, each built on its own
Hostify already runs several software agents in production:
| Agent | What it does today |
|---|---|
| David | Takes every Intercom support conversation, sorts it, answers from the Help Center through Vicky, asks Dexter to investigate, escalates to a person. Runs per topic in one of four modes: off, shadow, assist, auto |
| Dexter | Investigates for staff, read-only: the production data copies, the logs, the code. Answers in Slack and to David |
| Vicky | Answers product questions from a copy of the Help Center |
| Guest messaging agent | Answers or drafts replies to guest messages in the product's inbox |
| Reporting agent | Answers questions about a customer's data with charts and tables inside the product |
| Document reading service | Reads passports and ID cards during guest check-in |
Each was built by a different person at a different time, with its own rules, its own way of being deployed and its own place to look for knowledge. They work. What they lack is a shared memory and a shared rulebook, so the lesson one of them learns does not reach the others, and the way one of them is allowed to act is not the way the next one will be.
2.4 What the plan does about it
One memory for all of it (the next chapter), one shape for every process so the pieces fit (the chapter after), and the agents brought under the same rules as the people, with their decisions recorded in the same place.
3 One knowledge base for the whole company
The knowledge base is the engineering wiki inside the HostifyRoot workspace: a folder of plain text pages, kept in a private repository, read and written by people and by agents through the same tools. The word "engineering" in its name is historical. It holds every function that has written its process down, and the plan is for it to hold all of them.
3.1 What goes in
| Kind of page | What it answers | Examples |
|---|---|---|
| Source | What was said or found, kept as it was, never edited | A meeting note, a security review, a survey of a repository, a brief from the CTO, a postmortem |
| Compiled page | What we know about a system, a service, a topic, written from the sources with each fact pointing at its source | The service catalog, the data flows between systems, the production environments |
| Process | How a kind of work is done, in the common shape (the next chapter) | Support request handling, incident response, change and deploy, onboarding |
| Role and person | Who does what, who decides what, what each role needs and must read | The role pages, the roster, the organisation page |
| Convention | The rules each function works by | Working rules, the delegation policy, how we communicate outward, how secrets are handled, coding standards |
| Decision | What was decided, by whom, when, and why | One page per decision, including the ones an agent took under policy |
| Register | What is open and who owns it | The security open items, the technical and process debt |
| Status and log | What exists, what is in progress, what happened | The status page, refreshed at a sprint close; the append-only log |
3.2 How knowledge gets in and stays right
A new piece of knowledge arrives as a source: a document, a chat export, a note from a conversation, a report from a tool. It is saved as it was, dated and named. Then the pages that it changes are rewritten from it, and each changed fact points back at the source. The index is updated and a line goes into the log. Lint tools check that every page names its sources, that the structure is the one agreed, and that no decision is cited that a later decision overturned.
The important rules, in plain words:
| Rule | What it means in practice |
|---|---|
| The wiki is the source of truth | If a page and a person's memory disagree, the page wins or the page is fixed. If two pages disagree, one is wrong and is fixed the same day |
| Nothing lives only in one head or one chat | A practice that exists only there is listed as debt, with an owner and a proposal to write it down |
| Every fact has a source | A page without one does not pass the lint |
| Decisions are pages | A decision taken in a meeting, in Slack or by an agent is a page by the end of the day, naming who decided and quoting them |
| No secrets, ever | A page names where a credential lives, never its value. Pages carry a sensitivity mark (internal, confidential), and a document that leaves engineering, like this one, carries nothing marked confidential |
3.3 Who reads it, and why that matters
People read it to learn how we work. New colleagues read it on their first day: the onboarding process creates their page and points them at the reading list of their role. Agents read it before they act: an agent asked to draft a support answer reads the Help Center and the wiki, not its training memory; an agent asked to check a deploy reads the change and deploy process and the environments page. Tools read it too: the tool that tells a session who is working reads the people pages; the tool that checks a machine reads the role page's requirements table.
Because all three read the same pages, a correction made once reaches everyone, including every agent, the next time they look.
3.4 One knowledge base, two layers
Each product repository keeps a small wiki of its own for what only concerns that code. The company's knowledge base is the central one, and the two are kept in step by a tool that checks each repository's conventions against the central ones. There is no third layer: a team drive, a personal notebook or a chat pin is a source to ingest, not a place to keep knowledge.
4 One shape for every process, and an agent in each
4.1 The shape
Every process page in the knowledge base, whatever the function, has the same sections in the same order. A support engineer and an accountant open two pages that read the same way, and an agent given either page knows where to look.
| Section | What it says |
|---|---|
| Purpose | What the process is for, and the risk it controls, named plainly |
| Roles | Who takes part, including the agent, and what each is responsible for |
| Steps | The work in order, each step with what it produces |
| Agent in this process | The agent's mode today; what the agent always does; what it never does alone |
| Inputs and outputs | What the process reads and what it writes |
| Service levels and checks | How fast, how well, and how we know; "not defined" when the owner has not set them yet, with a proposal |
| Failure modes | The ways this work has gone wrong here, so they are not repeated |
| Related decisions | The decision pages that shaped the process |
Above the sections, a header names the owner role, the status (draft or active), what triggers the process and the sources it was written from. A page marked draft is a proposal; it becomes active when the owner has read it, corrected it and confirmed it. Only then can the agent's mode rise above "off".
4.2 Consolidation before automation
When the same work is done differently in two teams or two systems, the process is first written once, with the differences settled, and only then given to an agent. This is the single most important rule of the plan, because automating a process fixes it in place: an automated mess is harder to clean up than a manual one. The order is always the same: write the process once, agree it with its owner, give the agent its part, raise the agent's mode as the evidence allows.
4.3 What "an agent" means here
An agent is a program that reads, reasons in language, uses tools and writes. It can read a support conversation and the Help Center and draft an answer. It can read a change and the deploy process and list which preconditions are missing. It can read the alerts of the last hour and propose which system is at fault. It cannot be held responsible, so it is never the owner of a process; the owner is always a role held by a person.
The agent's part in a process is described in two lists on every page:
| List | What is on it |
|---|---|
| Always agent | The work the agent does every time, because it is repeatable and checkable: sorting what came in, gathering the evidence, drafting from the written sources, checking a list of preconditions, writing the record afterwards |
| Never alone | The work the agent does not do without a person, whatever the mode: a change in a customer's data, money, a promise of a date, a production step, a message to a customer on a topic not yet approved, closing an incident |
4.4 The four modes
Every agent part runs in one of four modes, decided per process and often per topic within it. The modes come from the way David already works in support, and the plan applies them everywhere.
| Mode | What happens | When it is used |
|---|---|---|
| off | The agent does nothing in this process | A process not yet confirmed by its owner |
| shadow | The agent does its part but nobody sees the result except the reviewer, who compares it with what the person did | The first weeks of every new agent part; the evidence for raising the mode |
| assist | The agent prepares; the person reads, corrects and acts | The normal mode for most processes |
| auto | The agent acts and records; the person reviews afterwards | Only where shadow and assist have shown the agent's work matches the person's, topic by topic, and only outside the "never alone" list |
A mode is raised by a recorded decision, with the shadow comparison as evidence, and lowered by anyone who sees a reason to, at once, with the reason recorded afterwards. The mode of each process is listed in the process map in the next chapter.
5 The Chief Operating Officer: the owner of how the company works
The hardest part of the plan is not the agents. It is the sentence in the company's goal that says "above all, consolidate and unify every practice and process". Agents can be given a part in a process in a week; getting eight functions to do the same kind of work in one agreed way is the work of a person with the authority to decide across all of them. That person is the Chief Operating Officer.
The CTO owns the machinery: the knowledge base and its tools, the agents and their guardrails, the pipelines. The CEO owns the product. Nobody, until now, owned the processes themselves as one whole: which exist, who owns each, how they are measured, where two teams do the same thing twice. This chapter describes the COO role as the CTO proposes it. The CEO confirms it; the role page in the knowledge base follows the confirmation.
5.1 What the COO owns
| Area | What the COO decides and keeps |
|---|---|
| The process map | That every function has its processes written in the common shape, each with a named owner, and that the map has no gaps. The map is the COO's working document |
| Consolidation | Where the same work is done in several ways, which way becomes the one way. The COO settles the difference; the owners then write it once |
| Owners | Who owns which process. A process without an owner is the COO's until one is named |
| Service levels | The targets on every process page: how fast, how well, how we know. The owners propose, the COO confirms, so that the levels are consistent across functions |
| Operational decisions | Windows, duty, escalation paths, the order in which processes are confirmed and given to agents |
| Readiness for an agent | Whether a process is confirmed and stable enough for its agent part to leave "off". The COO says the process is ready; the CTO says the agent and the tool are safe; the mode is a joint decision |
| The review rhythm | The weekly review inside each process and the cross-function review at the sprint close, where delegated decisions are read and the measures of progress are checked |
| The backlog of manual steps | The register of steps that are still "open the console and look", ordered by operational pain; the CTO prices and builds the tools |
5.2 What the COO does not own
The product, its design and its wording: the CEO. The technical choices: architecture, tools, security, releases, which agent runs where and under which guardrails: the CTO. A fork that is both operational and technical, or on which the two disagree, goes to both, with the evidence and a recommendation, as the organisation page already says for the CEO and the CTO.
5.3 How the three roles fit
5.4 The COO and the agents
The agents work, more than for anyone else, for the COO. Every "assist" and every "auto" rests on a process the COO has had confirmed; every shadow comparison is evidence the COO reads before raising a mode; every record an agent writes is a line in the registers the COO reviews. The agent's part in the business processes (the derived project status, the drafted handover, the reconciliation list) is the COO's instrument for seeing how the company runs without asking eight people for a report on Friday.
In return the COO holds the lever nobody else does: the mode. A process whose agent misbehaves is lowered to shadow by the COO at once, with the reason recorded afterwards, and nobody needs to ask the CTO first.
5.5 Who decides what, extended
The organisation page today names two deciders. The proposal adds a third row.
| Kind of fork | Decides | Examples |
|---|---|---|
| Product, design and UX | CEO | what a screen shows, a feature's scope, the order of features |
| Technical | CTO | architecture, standards, tools, security, releases, which agent runs where |
| Operational and process (proposed) | COO | how a process runs, its owner, its service levels, its window, whether it is ready for an agent, which of two ways of working becomes the one |
| Two kinds at once, or two deciders disagree | both, with the evidence and a recommendation | a process change that needs a new tool; a feature that changes how support works |
6 Every function and its processes
The whole plan in one table: every function, its processes, who owns them, their status and the agent's mode today. The table is taken from the mission page of the knowledge base as it stands on the day this document was built, so the two never disagree. A function with no row is the next gap.
6.1 The process map: the whole vision in one table
Every function of the company, its processes, who owns them, their status and the agent's mode. A function with no row is the next gap. Owners confirm drafts; only then is an agent mode raised above off.
| Function | Process | Owner role | Status | Agent mode |
|---|---|---|---|---|
| Engineering | Session start, Session end | CTO | Active | assist (hooks, lint, desk) |
| Engineering | Onboarding | CTO | Draft | assist (onboarding skill) |
| Engineering | Release and change: see Operations; code review and the commit gate: working rules, standard 09 | CTO | Active (rules), gate pending (DEBT-006) | assist |
| Product | Discovery to delivery; rulings per decisions and rulings | Product Owner / Manager (CEO decides) | Draft (template) | assist |
| Project management | Project delivery | Project Manager | Draft (template) | assist; auto for status derivation |
| Support | Support request handling | Support Engineer | Draft | off / shadow / assist / auto per topic (David today) |
| QA | Release verification | QA Engineer | Draft | shadow |
| Operations | Incident response | DevOps / SRE | Draft | shadow |
| Operations | Change and deploy | DevOps / SRE | Draft | assist (staging auto where the pipeline already is) |
| Sales | Lead to customer | Sales | Draft | shadow |
| HR | People lifecycle | HR | Draft (template) | shadow |
| Accounting | Billing, collections and month close | Accounting | Draft (template) | shadow |
| Every function | The knowledge base itself: ingest, query, decide, digest, lint (hostify-wiki skill) | CTO | Active | auto for lint and ingest, assist for decisions |
6.2 Reading the table
- Owner role is a role, not a person. The roster maps people to roles; several roles still have nobody in them, which is itself an open item on the organisation page. The COO is not an owner of single rows but of the map as a whole: that every row has an owner, a status and a mode, and that no function is missing.
- Status is "Draft" until the owner confirms the page. The engineering rituals and the knowledge base's own process are active because they are used every day in the workspace.
- Agent mode is the mode today, not the goal. Most draft processes start at shadow or off. Support is the most advanced because David has run there longest.
6.3 Every fork has a decider
The map works because every fork has a known decider. The rule is short and is copied here from the organisation page.
6.4 Who decides what
| Kind of fork | Decides | Examples |
|---|---|---|
| Product, design and UX | CEO | what a screen shows, its layout and wording, a feature's scope, a reduction, the order of features |
| Technical | CTO | architecture, standards, tooling, the gate, dependencies, the toolchain version, security, releases and deploys |
| Both kinds at once, or the two disagree | both: the session stops and puts it to both, with the evidence and a recommendation | a design that needs a new dependency; a feature cut for technical cost |
A ruling is recorded as a page in decisions/ naming the person and quoting them, the same session. The CEO's executive override applies only after a technical fork has gone to both, and only after the warning described on Role: CEO.
Teams are not yet defined. A natural first cut follows the estate in the ecosystem map: Legacy (six clusters), Platform (AWS edge, Cal2, Atlas), Guest and Operations (MrGG, Tasks, mobile), Facelift, and AI. Team pages are created only when the CTO confirms them.
The table names two deciders. The chapter on the COO proposes the third row: operational and process forks (how a process runs, its owner, its service levels, whether it is ready for an agent) are the COO's; a decision that changes a tool, a pipeline or a security rule stays technical and goes to the CTO; a fork that is both goes to both. See the extended table.
7 A support request, end to end
Support is the function where the plan is furthest along, so it is the clearest example of how a process and an agent fit together. The process page is "Support request handling"; its owner role is the Support Engineer.
7.1 The steps
- Intake. A conversation arrives in Intercom. David reads it and classifies it: a question, a defect, a data request, a feature request, a billing matter. The customer and the system they are on are identified from the records, never guessed.
- Evidence first. Before anyone answers, the evidence is read: the logs, the copy of the production data, the Help Center. Dexter does this on request, read-only. A finding is quoted with where it came from. Nothing in the customer's data is changed at this step.
- Answer or escalate. A question is answered from the Help Center and the knowledge base, with Vicky drafting. A defect is reproduced and handed to the engineering role that owns the system, as a row in the register with the evidence attached. A data request is executed only with the customer's written ask and a logged staff session.
- Close with a record. The outcome is written back: a Help Center article corrected or added, a recurring issue saved as a source for the knowledge base, a defect linked to its register row.
- Review. Weekly, the Support Engineer and the Engineering Manager read the recurring issues and compare the agent's shadow answers with the human answers, topic by topic.
7.2 Where the agents act
| Agent | Part | Mode today |
|---|---|---|
| David | Takes every conversation, classifies, drafts, delegates, escalates | off, shadow, assist or auto, decided per topic |
| Dexter | Gathers evidence from data and logs, read-only | assist (on request) |
| Vicky | Drafts product answers from the Help Center | assist (through David) |
7.3 What the agent never does alone
A change in a customer's data. A refund or any billing action. A promise of a date. A message to a customer in auto mode on a topic that has not been approved for auto.
7.4 What changes for the people
The Support Engineer stops being the person who remembers and becomes the person who decides: which answer goes out, which defect is real, which topic has earned auto. The twenty-first time the same question is asked, it is already an article or a defect, because step four made it one. The weekly review is where the mode of each topic is raised or lowered, with the shadow comparison as the evidence.
8 Operations: incidents, changes and deploys
Two process pages belong to Operations. Both are drafts written from the engineering survey of the estate and from the CTO's brief; both wait for their owner to read them, correct them and confirm them. Their owner role is DevOps / SRE, and the COO confirms their service levels and their windows.
8.1 Incident response
The purpose written on the page: an outage or a security event is detected, contained, resolved and learned from in a known order, with a record that lets the next incident go faster. The risk it controls is the one the estate has today: several production clusters and a ring of smaller systems with no shared runbook, a data copy that stops updating unnoticed, a disaster-recovery clone mistaken for production.
The steps, in short: declare the incident with a severity and a lead; assess which system and which flow from the data-flows page; contain with the smallest reversible action first; resolve through the pipeline, never by a hand edit on a host; communicate to customers through Support and update the status page; write the postmortem within a few business days and save it as a source for the knowledge base.
The agent's part, in the mode "shadow" until runbooks exist: correlate the alerts and logs, propose the affected system from the data-flows map, draft the timeline and the postmortem, open the register rows. The agent never changes anything on a production host, never rotates a credential, never speaks to a customer and never closes the incident.
8.2 Change and deploy
The purpose: every production change is made by a pipeline from a reviewed commit, with a rollback step known before it starts and a record after. The risk it controls: the manual steps the estate still has, such as SQL applied by hand on each cluster, deploys run from a workstation, settings changed in a console with no record.
The steps: check the preconditions (a green verification record, the pipeline pointed at the right branch, the migration in the repository, the rollback written); declare the window and tell Support; execute by the pipeline, one cluster at a time; verify with a read-only smoke test and watch the first hour; write the change record. Infrastructure changes follow the same steps with a second reviewer.
The agent's part, in the mode "assist": run the precondition checklist, draft the change record, watch the first hour and report the comparison with the hour before. Staging deploys that the pipeline already runs on its own stay automatic. The agent never runs a production step, never applies an infrastructure change and never decides a rollback.
8.3 What the COO is asked to settle
Both pages carry "Service levels and checks: not defined" with a proposal beside it. For incidents the proposal is a severity scale, a response time per severity and the postmortem deadline. For changes it is a target of zero workstation deploys to production within a set period and a change record for every cluster deploy. The owners propose them and the COO confirms them, in the words of how the work is actually done.
8.4 How the two processes feed the knowledge base
Every postmortem and every change record is a source. The incident process ends with the runbooks updated; the change process ends with the service page's deploy section pointing at the record. After a quarter of this, the question "what happened the last time this system failed" has an answer on a page, and the agent correlating the next incident reads it first.
9 Development: a working session
Engineering is where the plan started, and its daily ritual shows what "an agent in every process" looks like when the process is mature. Every engineer, and every agent working on the code, works in the same workspace with the same tools. These are active processes, used every day.
9.1 The session starts knowing who you are
When a working session opens, a tool reads the identity the person commits with, finds their page in the knowledge base, and prints their role, their personal working rules and their open work. An identity nobody has seen before means a new colleague, and the session switches to onboarding before anything else: a person page is created, the role's reading list is handed over, and the machine is checked for what the role needs. Nothing about how to behave is remembered privately by the agent; it is all on pages anyone can read and correct.
9.2 The session ends with nothing left behind
The end of a session is a checklist that the agent runs and a hook enforces:
- The code written in the session is reviewed, and the review's findings are fixed or recorded as debt with a proposal.
- The knowledge base is linted: every page names its sources, the structure is the agreed one, no overturned decision is cited.
- Every new debt row has an owner and a proposal.
- The log has a line for everything ingested, decided and linted.
- A handoff is written so the next session, by this person or another, starts from the handoff alone.
- The work is committed and pushed. A commit that was not pushed does not count as done.
- The final message to the person closes with a table of recommendations: what, why, cost, priority, who decides.
A session that tries to end while work is still running is refused by the hook until the work is finished or stopped.
9.3 Review and the gate
Code is reviewed before it is committed, and a commit gate records the reviewed state of the tree so that work written after the review cannot ride along unreviewed. Conventions are written once centrally and each repository is checked against them by a tool. A repository that drifts from the central conventions shows up in the check, not in a code review months later.
9.4 Where the agent is, and where the person is
The agent runs the steps, writes the pages, drafts the decisions and proposes the debt rows. The person decides the forks the delegation policy reserves for them, reads the recommendations table and rules on what waits for them. Every decision the agent took on its own under the policy is a page marked as delegated, so a person can read all of them at the sprint close and correct the policy where it went wrong.
9.5 Why this chapter is here for Operations
Because it is the template. The support process got there second, the operations processes are next, and the business functions after that. The shape of a mature process is the same everywhere: a known start, written rules the agent reads, a checklist the agent runs, a record at the end, a person deciding the forks.
10 Product, projects, QA, sales, HR and accounting
The plan is for the whole company, not for engineering. Each of these functions already has a process page in the knowledge base, in the common shape. Most are templates: the shape is there, the steps are a proposal, and the owner has not yet read them. They are listed so that nobody mistakes the current state for the goal.
| Function | Process page | What it covers | State |
|---|---|---|---|
| Product | Discovery to delivery | How an idea becomes a shipped feature; how product rulings are recorded | Draft template; the CEO decides product forks |
| Project management | Project delivery | How a project is planned, tracked and closed; status derived from the work, not typed | Draft template; status derivation proposed as the agent's auto part |
| QA | Release verification | How a release is verified before it goes out; the verification record the deploy process requires | Draft; agent in shadow |
| Sales | Lead to customer | From a lead to a signed customer, with the handovers to onboarding and support | Draft; agent in shadow |
| HR | People lifecycle | Hiring, onboarding, changes of role, leaving; the parts that touch the workspace are already live through onboarding | Draft template; agent in shadow |
| Accounting | Billing, collections and month close | Invoicing, collections, the month's close | Draft template; agent in shadow |
10.1 What the agent does in a business process
The same kinds of work as in engineering, translated: sort what came in, gather the evidence, draft from the written sources, check a list, write the record. In project management the agent derives the status of a project from the tasks and commits instead of someone typing it on a Friday. In sales it drafts the handover note from the conversation record. In HR it runs the onboarding checklist and keeps the role pages and the roster in step. In accounting it reconciles what the systems say against each other and lists the differences; it never moves money.
10.2 What each owner is asked
To read their page, to correct the steps to how the work is really done, to write down the failure modes they have lived through, and to set the service levels. Then to confirm it. The agent's mode rises only after that, and only through shadow first. The CTO's office helps with the writing; the owner supplies the knowledge.
11 Tools a person and an agent can both run
An agent acts through tools. If the only way to do something is to click through a web console, an agent cannot do it, and neither can a colleague who was not shown where to click. So the plan sets the same rule for every tool the company builds for its own work.
11.1 The rules every tool follows
- It explains itself (
--help), so a person or an agent can learn it without asking. - It can answer in a form a program reads (
--json), so the next tool in the chain can use the answer. - It runs on every operating system the company uses, in one language (Python), with no hidden dependency on a shell.
- Anything that acts outward (sending a message, publishing a page, deploying, deleting, writing into another repository) is a dry run by default and needs an explicit flag to really do it. The flag prints itself into the record, so the record shows what was really done.
- It never prints a credential. It names where one lives.
11.2 The tools that exist in the workspace today
| Tool | What it does | Who runs it |
|---|---|---|
| Identity | Resolves who is working from their commit identity, and prints their role and rules | Every session, automatically |
| Doctor | Checks that a machine can work with the workspace and that the person's role has the credentials it needs, by name only | A person on a new machine; onboarding |
| Keys | A small local web page that helps a person fill in and test each credential their role needs, by trying it, and copies credentials by name from a sibling project | A person, once per credential |
| Wiki lint | Checks the knowledge base: sources named, structure agreed, decisions not overturned | Every session end; the agent |
| Conventions check | Checks a repository against the central conventions | The agent; a sprint close |
| Threads and desk | Keeps each person's open work, handoff and inbox in order | The agent, every session |
| Mail, Slack, tasks, Intercom, Zendesk | Read and, with the explicit flag, write to the systems the processes use | The agent under a process; a person |
The connection to each outside system is a reviewed tool in the workspace, under the company's control and its review, not a third-party plug-in. The task tracker is reached through a port with the current tracker behind it, so changing trackers changes one adapter, not every process.
11.3 Why this concerns Operations
Every operations process names tools in its steps: the pipeline, the monitoring, the status page, the ticket system. For the agent to take its part in incidents and deploys, those steps need to be reachable through tools that follow the rules above. Where today a step is "open the console and look", the plan writes a tool for it. The list of such steps is itself a register, and Operations knows it best.
12 The guardrails
A company that lets programs take part in its processes needs clear rules about what they may decide. Hostify's rules are written in the delegation policy and the working rules, and they apply to every agent in every function, the same way the working rules apply to every person.
12.1 What an agent decides alone
The policy names the kinds of fork an agent may decide without asking, and for each the condition. In plain words:
| Kind of fork | The agent's rule |
|---|---|
| Simpler now or more powerful later | Pick the simpler; complexity can be added later, the reverse is expensive |
| Cheap to undo | Decide, record a one-line note marked "delegated", continue |
| Decided before | Follow the earlier decision, citing it; check first that nothing later overturned it |
| An open question to Hostify with a written recommendation | Decide by the recommendation, record it, build it behind one named seam so a different answer later is one change |
Every one of these decisions is a page, marked as delegated, naming the policy row that allowed it. The visibility is never delegated, only the decision. At every sprint close a person reads all the delegated decisions of the sprint; anything that stings becomes a correction to the policy, dated.
12.2 What an agent never decides
The policy also names the forbidden zone, because a policy without one creeps:
- Anything irreversible or expensive to reverse: production data structures, public contracts.
- Anything external: communication with customers or partners, production deploys, new dependencies.
- Anything with money.
- Taking a capability away from a user, however small the change looks.
- A choice that narrows or declines an explicit instruction from the person.
- Any fork whose kind the agent is not sure of. Being unsure is itself a reason to ask.
These hold in every mode, including auto.
12.3 How a question reaches a person
When an agent must ask, it asks with evidence and a recommendation: what exists now, what the options are, which one it recommends and why. A person then decides in one line, and the decision becomes a page. The same form is used for every function, so a COO and an engineer receive questions that read the same way.
12.4 Secrets and sensitivity
No credential value is ever written into a page, a tool's output or an agent's memory; only the name of where it lives. Every page carries a sensitivity mark, and a document that leaves engineering carries nothing marked confidential. An agent that needs a credential gets it through the keys tool, the same way a person does, and the tool proves the credential works by trying it, never by printing it.
12.5 Who watches the agents
The owner of each process, weekly, through the review step that every process has. The CTO, at the sprint close, through the delegated decisions. Everyone, at any time, through the log and the decision pages, which are readable by the whole company. An agent whose work cannot be followed from the record is, by the working rules, a delegation that should not have happened.
13 How progress is measured
The plan is measured by what is written down and confirmed, not by how many agents run. The measures below are the ones on the mission page; they are read from the knowledge base by a tool, so they cannot be improved by typing a better number.
| Measure | What it tells |
|---|---|
| Process pages per function, and how many are active rather than draft | Whether the owners have confirmed how their work is done |
| Processes with an agent mode above off, and how many at each mode | How far the agents have earned their part, topic by topic |
| Repositories aligned with the central conventions | Whether engineering works one way or several |
| Practices found in more than one shape and merged | Whether the consolidation is happening, from the knowledge base's own tidying log |
| Service levels defined rather than "not defined" | Whether Operations and the owners have set the targets |
| Decisions recorded, and delegated decisions corrected at the sprint close | Whether the guardrails are alive |
13.1 What "done" looks like for one process
A process is done, in the sense of this plan, when its page is active, its owner has set the service levels, its failure modes are the real ones, the agent's part runs in the mode the evidence supports, and the last three occurrences of the process can be read from the record alone. After that it is maintained, not finished: every incident, every review, every correction goes back into the page.
13.2 What is deliberately not measured
How many conversations the agents answered, how many hours they saved, how many tickets were closed. These are easy to inflate and say nothing about whether the company works one way. They may be reported by the functions for their own purposes; they are not the measure of the plan.
14 What this asks of the COO
The plan needs from the COO what nobody else can give: the authority to decide across functions, and knowledge of how the operational work is done today. The asks are concrete and ordered.
14.1 First: the role, confirmed and written
The knowledge base has no page for the COO yet, neither as a role nor as a person. The organisation page names the CEO and the CTO as deciders and lists DevOps / SRE under the CTO; Operations as a function with its own head is not there. The first step is the CEO's confirmation of the role as the previous chapter describes it, then a short session with the CTO's office: the role page with its responsibilities, access and reading list, the person page, and the third row in the who-decides table. That is what makes the rest possible: a process can only be confirmed by someone the knowledge base knows.
14.2 Second: take the process map as the working document
The map in the knowledge base is the list of what exists and what is missing. The COO reads it, adds the functions and processes it lacks, and names an owner for every row that has none. From then on the map is refreshed by the knowledge base's tools and read by the COO at every sprint close.
14.3 Third: read and confirm the two operations processes
Incident response and change and deploy, as described earlier. Reading each takes a quarter of an hour. Correcting it to how the work is really done is a conversation with the people on duty. The confirmation is one line, recorded as a decision. The other functions' owners then do the same for their pages, in the order the COO sets.
14.4 Fourth: set the service levels
Every process page that says "not defined" is waiting for its owner's proposal and the COO's confirmation. For incidents: the severity scale, the response time per severity, the postmortem deadline. For changes: the window rules, the target for workstation deploys, what a change record must contain. For support, with the Support Engineer: the first-answer time and the defect-reproduction time. The COO keeps the levels consistent across functions.
14.5 Fifth: decide the starting modes with the CTO
For each process, and for each topic within it where that makes sense, the mode the agent starts in. The recommendation on the operations pages is shadow for incidents and assist for the change checklist. The COO says the process is ready; the CTO says the agent is safe; the mode is a decision page and can be lowered by the COO at any time.
14.6 Sixth: settle the duplicates and name the manual steps
Where the same work is done in two ways (a deploy by pipeline here and by hand there, an answer from the Help Center here and from memory there), the COO decides which way becomes the one, and the owners write it once. The steps that are still "open the console and look" or "run this from my laptop" go into a register, ordered by operational pain; the CTO prices and builds the tools.
14.7 What the COO gets back
One map of how the company works, with an owner for every process and a target for each. A record of every incident, every change and every support outcome that can be read later without asking anyone. Agents that do the correlation, the checklists, the drafts and the paperwork, in the modes the COO chose, under rules the COO can read and lower at will. And one shape for every process, so that a question about support, deploys or billing is answered the same way, by a person or by an agent.
14.8 Where to read more
The mission page in the knowledge base (wiki/company/mission-agentic-first.md) is the one-page version of this document. The process pages are under wiki/processes/. The organisation page is wiki/people-teams/org-structure.md. Access to the workspace is granted at onboarding; the first session opens with the reading list of the role.
15 Recommendations
What we recommend, in order, with who decides each. The costs are estimates in sessions and hours of the people named, not in money.
| No. | What | Why | Cost | Priority | Who decides |
|---|---|---|---|---|---|
| 1 | Confirm the COO role as described in this document; add it to the organisation page as the third decider, with a role page and a person page | The plan has an owner for the product and for the technology and none for the processes as a whole; nothing below can be confirmed by someone the knowledge base does not know | One decision, then one session with the COO present for half an hour | High | CEO confirms; CTO writes the pages |
| 2 | The COO takes the process map as the working document: adds the missing functions and processes, names an owner for every row | The map is the plan; a row without an owner is a process nobody will confirm | Two hours, then a quarter of an hour at each sprint close | High | COO |
| 3 | Read, correct and confirm the incident response and the change and deploy pages | Both are drafts written from the engineering survey; the knowledge of how the work is really done is missing | An hour of reading and one conversation per page | High | COO with the people on duty; confirmation recorded by the CTO's office |
| 4 | Set the service levels marked "not defined", operations first, then support with the Support Engineer | Without targets the processes cannot be checked and the agents' shadow results cannot be judged | Two hours | High | Owners propose; COO confirms |
| 5 | Decide the starting agent mode per process: shadow for incidents, assist for the change checklist | The mode is the lever the COO holds over the agents; a recorded decision makes the lever visible | Half an hour, one decision page each | Medium | COO and CTO |
| 6 | Settle the duplicated ways of working, one at a time, and list the manual steps as register rows | Each duplicate is a process that cannot be given to an agent; each manual step is one the agent cannot take and a colleague cannot repeat | One afternoon for the list; the duplicates one conversation each; tools priced one by one afterwards | Medium | COO settles and lists; CTO orders the tools |
| 7 | Bring the existing agents (David, Dexter, Vicky, guest messaging, reporting) under the knowledge base and the delegation policy, one at a time | They were built separately; a lesson one learns does not reach the others, and their rules differ | One session per agent for the survey and the page; changes to the agents priced after | Medium | CTO; the COO sets the order |
| 8 | A quarterly read of this document against the process map | The map is the measure; the document should say the same thing or be rewritten | An hour per quarter | Low | CTO's office |
16 Glossary
| Term | Meaning in this document |
|---|---|
| Agent | A program that reads, reasons in language, uses tools and writes; given a part in a process under rules a person set. Never the owner of a process |
| Agent mode | How much an agent does in a process: off, shadow, assist or auto. Decided per process and often per topic, by a recorded decision |
| Always agent / never alone | The two lists on every process page: what the agent does every time, and what it never does without a person |
| COO | The Chief Operating Officer: the proposed owner of how the company works, across every function: the process map, the owners, the service levels, the consolidation of duplicated ways of working, and the readiness of a process for an agent. Decides operational and process forks, as the CEO decides product and the CTO technical ones |
| Consolidation before automation | The rule that a process is written once and agreed before an agent is given a part in it |
| Decision page | A page recording what was decided, by whom, when and why. Agents' own decisions are pages too, marked as delegated |
| Delegation policy | The written rules for which kinds of decision an agent takes alone, which it records, and which it never takes |
| Draft / Active | The status of a process page: a proposal until the owner confirms it, active afterwards. The agent's mode rises above off only on an active page |
| Failure modes | The ways a process has gone wrong here, written on its page so they are not repeated |
| Handoff | The note a working session leaves so the next session starts from it alone |
| HostifyRoot | The shared workspace: a private repository holding the knowledge base, the people's threads, the tools and the agent configuration, used by everyone through the same tools |
| Ingest | Saving a new source as it was, then rewriting the pages it changes with each fact pointing at it |
| Knowledge base, wiki | The pages under wiki/ in HostifyRoot: the one place the company's knowledge of how it works is kept |
| Lint | A tool that checks pages or code against the agreed rules and reports what does not pass |
| Owner role | The role responsible for a process. A role, held by a person, never an agent |
| Process page | A page describing how a kind of work is done, in the common shape: purpose, roles, steps, agent, inputs and outputs, service levels, failure modes, related decisions |
| Register | A list of open items with owners: the security open items, the technical and process debt |
| Service levels | How fast and how well a process must run, and how we know. "Not defined" on a page means the owner has not set them yet |
| Shadow | The agent mode in which the agent works but only a reviewer sees the result, compared with what the person did; the evidence for raising the mode |
| Source | A document, note, review or report saved as it was, dated, never edited; the thing every page points back at |
| Sprint close | The regular review at which delegated decisions are read, the status page is refreshed and the policy is corrected |