From company structure to governed work.

Give AI work an accountable place in your company.

The architect starts with how the organisation works: its departments, teams, responsible roles and reporting relationships. An assistant belongs to a role with a defined job. The person occupying that role remains the owner of the responsibility.

What to prepare

Choose one responsibility to start with. Bring its owner, reporting manager and a short description of the work. In the fictional Northstar example, Sofia handles supplier invoices and reports to Marcus in Finance.

Walk through the setup

1. Place the work. Identify the department and team where the responsibility belongs.
2. Name the role and its owner. A role is a continuing position; its occupant can change. This keeps the company's structure distinct from the people currently filling it.
3. Connect the assistant. Give the role's assistant a specific purpose, such as reviewing supplied invoice information.
4. Check the reporting relationship. Inspect the owner and manager together before proceeding to instructions and limits.

Ready for the next chapterYou can explain whose work the assistant supports, where that responsibility sits and who the person reports to.

What to notice in the recording

0:06–0:19: follow Sofia's role, manager and assigned instructions. The remaining scenes introduce the limits and checks we unpack in chapter 3. Explore the organisation model.

Turn a responsibility into instructions the assistant can use.

The architect or procedure owner describes how the work should be approached. A reusable procedure makes the expected checks and answer format explicit, so a person does not have to repeat the entire method with each request.

What to prepare

Start with an existing procedure or a short written account of the job. Identify the information the assistant needs, the checks it should make, what to do when evidence is missing and the result the user expects.

Walk through the setup

1. Save the procedure. Give the instructions a clear purpose that someone else can inspect.
2. Assign it to the intended assistant. Check that the invoice procedure is attached to the assistant doing that job.
3. Inspect the preview. Read the instructions the assistant will receive. Look for missing context, unsupported assumptions and the expected response format.
4. Compare a later answer. After work runs, inspect whether the answer reflects the assigned guidance and handles missing evidence clearly.

Ready for the next chapterThe assistant has an inspectable method for its job. Next, configure what it is permitted to do and which information it may use.

In Aegis, Harness groups a specialist’s instructions and resources. This chapter covers its reusable instructions; inspect the wider builder configuration on Platform.

Instructions can also be published for reuse. In the Operations example, Daniel saves a handover format, assigns it to a specialist and publishes that specialist to his unit, so Avery can select the same one. See the shared specialist and reviewed handover →

What to notice in the recording

0:00–0:16: saved instructions are assigned and previewed. 0:16–0:31: a saved later answer uses the headings without the request naming them. Follow the builder walkthrough.

Decide what may proceed, what needs review and what is outside the assistant's responsibility.

The architect configures operating controls alongside the instructions. A procedure explains how to approach the work; controls establish the allowed actions, review requirements, information access and spending limits.

Separate the decisions

When a person must review

The Northstar example requires review above $1,000. It also requires human review for payments. A low amount alone is therefore not permission to make a payment.

The maximum permitted amount

The example sets a $5,000 transaction maximum. Treat the review threshold and the maximum as different controls when defining the responsibility.

Which actions are allowed

The invoice example forbids bank-detail changes. Write down these action boundaries as well as any monetary limits.

How much AI work may cost

The separate $10 AI-running budget concerns the cost of using AI. It is not the amount of an invoice or a payment allowance.

Also specify when the authority applies and expires, and who the assistant may contact through which channels. These are separate operating choices alongside spending, actions and information.

Check information access separately

Identify the reference material the job needs and who may use it. Information classification and organisational access are separate checks; a senior title does not by itself grant access to every record. In the recording, a reference is reviewed and published, then two assistants receive the same question. One cites the reference; the other cannot read it with its current permissions.

Ready for the next chapterYou have identified the permitted work, the decisions requiring review, the relevant information permissions and the separate AI budget.

What to notice in the recording

0:00–0:33: follow publication and the two different access outcomes. 0:33–1:03: a separate directive records a reading acknowledgement. Explore information controls.

Give the assistant the specific outside capability its job needs.

MCP (Model Context Protocol) is a common way for an AI assistant to use tools offered by another service. Connecting a server does not grant unrestricted permission to use it.

The architect and operator connect an existing service and assign an appropriate tool. A tool supplies a capability, such as reading information from another system. Its assignment, the request to use it and the returned result are distinct points to inspect.

What to prepare

Identify the service, the operation needed for the job and the information the request will use. Decide whether the work requires reading information or changing a record, and identify the applicable review requirements.

Walk through the connection

1. Discover the available tools. Inspect what the connected service offers.
2. Assign the required operation. Choose the tool needed by the intended assistant.
3. Inspect the request. Check which tool the assistant wants to call and what it is asking the service to do.
4. Complete the required review. In this recording, Avery approves the agent escalation and then the separate tool-gate hold.
5. Inspect the returned result. Connect the service response with the assistant's answer.

Ready for the next chapterYou can trace the capability from assignment through its request, required review and result.

What to notice in the recording

0:00–0:16: the unchanged final answer, shown as an outcome preview. 0:16–0:26: the existing assistant and tool assignment. 0:26–0:42: Avery’s agent decision. 0:42–0:54: the separate tool approval. 0:54–1:04: the returned category names. 1:04–1:20: the consistent final answer and the limits of this one observation. Explore the MCP example. Explore the technical builder controls.

Describe the outcome and supply the information needed to work on it.

The user brings the task to the prepared assistant or workflow. An objective explains what the person wants to achieve. The supplied facts and documents give the assistant material to work with, while the assigned instructions establish the method.

Prepare a useful request

• Outcome: state what you need, such as a review summary or a shift handover.
• Evidence: supply the document or facts relevant to that request.
• Expected answer: name the information the result should contain.
• Scope: make clear which work you are asking for, including any requested record changes.

Follow the work

1. Open the prepared workflow. Inspect the connected steps and the input it expects.
2. Supply the facts and run it. In this example, three steps take the dock details, produce a summary and return the answer.
3. Read the result against the request. Check that it reflects the supplied facts and makes missing information clear.
4. Identify the next decision. A returned answer may support a review or further work; check what outcome the request actually achieved.

Ready for the next chapterYou have an answer connected to the supplied input and can identify what still needs a person's decision.

In the Operations example, Avery runs Daniel's published specialist inside a saved three-step pipeline. Both colleagues run it with the same facts, and both outputs follow the assigned four-heading format. Follow the shared pipeline through to its result →

What to notice in the recording

0:00–0:24: inspect the saved workflow and the supplied details. 0:24–0:48: follow completed steps into the resulting summary. Explore everyday work demonstrations.

Give the responsible reviewer the evidence and the decision together.

The authorised reviewer examines the request that has been held. The useful question is specific: does the supplied evidence support proceeding with this work? Keep the original document, the extracted information and the decision connected.

What the reviewer checks

1. Confirm the request. Open the document and check that the review belongs to the intended work.
2. Compare the evidence. Inspect the buyer, supplier, amount and other relevant details against the company and purpose of the request.
3. Record the decision and reason. Explain the issue clearly enough for the person requesting the work to act on it.
4. Inspect the resulting state. Confirm what happened to this request after the decision.

Make the next action clear

Here the next action is to obtain the corrected invoice. The reviewer has identified a concrete document problem and recorded why the request stops. This makes the decision useful to the requester as well as visible in the work history.

Ready for the next chapterThe request has an attributable decision, a recorded reason and a clear next action for the person handling it.

In the Operations example, Avery saves the generated handover into Knowledge and Daniel reviews that same unchanged document. Read the handover Daniel reviewed →

What to notice in the recording

0:00–0:30: follow the document and the buyer mismatch. 0:30–1:00: inspect Marcus's rejection and the stopped state of that same request. Explore the complete document decision.

Use experience to improve the instructions for later work.

The procedure owner reviews a proposed improvement, and the operator checks its assignment to the assistant. A useful draft can still contain unsupported assumptions. Read and edit the proposal before accepting the guidance that will be used again.

Walk through the improvement

1. Start from the work. Inspect the recorded result and the proposed steps for future use.
2. Check each assumption. Look for references to information or capabilities the assistant does not have.
3. Edit the guidance. Keep the useful method and remove the unsupported instruction.
4. Accept and inspect the saved procedure. Check the accepted proposal and the retained instructions in the library.
5. Check assignment and later use. Preview the assistant's instructions, then examine a later answer for the expected guidance.

What the owner is deciding

The review concerns the content of the procedure: whether it is useful, supported and appropriate for the job. Assigning that procedure does not itself grant new authority or information access. Those controls remain part of the operating setup.

Ready for the next chapterYou can follow a proposed improvement through the edit, saved instructions, assignment and later answer.

What to notice in the recording

0:07–0:33: inspect the unsupported assumption, edit and acceptance. 0:40–1:11: follow the library entry, assignment and later answer. Explore reviewed instruction improvement. Watch a separate test, instruction change and retest.

Keep responsibility and reporting relationships current as the company changes.

The architect updates the organisational structure and inspects its consequences. A role can keep its assistant while its place in the company changes. Check reporting, authority and information access as distinct parts of the update.

What to prepare

Identify the team being moved, the current and intended reporting manager, and the responsibilities that should continue. Make a note of the information the role needs so that access can be checked after the move.

Walk through the change

1. Inspect the starting position. Confirm the existing department, reporting manager and role-assistant connection.
2. Make the intended updates. The recording changes the reporting manager and moves the team as separate actions.
3. Check the resulting responsibility. Inspect the new reporting line and whether the assistant remains connected to the role.
4. Inspect authority and access. Check the changed authority links, then separately check the information the role and assistant can use.

Ready for the next chapterYou can describe the new reporting relationship, the changed authority and the information access observed after the move.

What to notice in the recording

0:00–0:30: compare the starting structure, changed manager and retained assistant. 0:30–0:50: inspect authority links and the separate reference-access result. Explore the team-move example.

Review what happened, what it cost and which settings need attention.

The operator and assurance reviewer follow a completed answer into its operating records. Start with a particular request so that the response, model usage and estimated cost can be examined together. Configuration history provides a separate way to inspect and maintain the settings used for work.

Inspect a run

1. Find the request and answer. Confirm that the result belongs to the work you are reviewing.
2. Inspect usage and spending. Read the recorded model usage, estimated cost and remaining budget. The estimate uses configured prices.
3. Inspect the activity record. The example checks the signed record for changes after the answer has been produced.
4. Check the outcome. Distinguish the answer that completed from the wider objective. In this example the answer completed while the objective remained open.

Compare and restore configuration

Open the saved versions, inspect the differences and choose the earlier configuration when restoration is appropriate. In the second recording, only the description was deliberately changed. After restoration, the comparison reports that all 15 supported settings match. Review the resulting settings before using them for further work.

Complete the operating cycleYou can inspect the outcome and spending of a particular run, review its activity record, and compare the configuration needed for subsequent work.

What to notice in the recordings

Run record, 0:10–0:50: follow the answer into usage, remaining budget and the signed-record check. Configuration, 0:07–0:31: inspect the changed description and restored settings. Explore run records and operating oversight.