The project went beyond changing a few settings. First, a debloat skill was used. A skill brings a repeatable way of approaching a task, rather than making the agent rediscover the procedure each time. We will return to that idea in a moment. Then a new launcher was built from scratch and used in place of the default home screen. The point was to have the interface and clean experience the owners wanted. They added media playback widgets, including Spotify, a weather widget, and other personal touches. The device started to feel like their home rather than someone else's advertising surface. They also built a companion Android app to control the TV. It offered buttons over Wi-Fi or IP—Internet Protocol, communication over the network—and an air mouse over Bluetooth. [Presenter cue: walk through the accepted S02 launcher and P03 Touchpad / air mouse captures, both 4 Nov 2026. Spotify is paused. P03 says Not connected: it demonstrates the UI, not current live connectivity or verified air-mouse motion. Privacy masks are preserved. Explain one design choice and one iteration.] This is a story about customization and agency. We are not claiming a measured performance gain. And changing system software carries risks: permissions, compatibility, and a way to recover still matter. The inspiring part is that a familiar frustration became something you could actively improve.

Let us separate the ingredients in that story. The goal was human: make the TV feel cleaner, more useful, and more personal. The debloat skill brought reusable know-how. The coding work needed a working environment and tools to inspect files, change code, and check results. The owner still had to choose the desired experience and judge what worked. I am deliberately not putting exact commands or an invented architecture on this slide. We have the project story, not a verified inventory of every tool used in that separate conversation. What we can take from it is the pattern: define an outcome, provide context, take a bounded step, inspect the result, and iterate. Now we can give those pieces names. If a term seems abstract, keep the TV in mind. We are naming the things that made that practical work possible, not collecting vocabulary for its own sake.

For this session, think of an agent as a system that can work towards a goal through a loop. It looks at the context and chooses a next step. It may call an available tool. It observes the result and decides whether to continue, change approach, or ask for help. A model is part of that system, but the model alone is not the whole experience. Instructions, tools, context, controls, and feedback matter too. In the TV example, useful progress meant more than describing a nice launcher. It meant helping produce something the owner could inspect and improve. An agent is not necessarily fully autonomous. It can stop for approval. It can work on a small task. It can also get things wrong, repeat an unhelpful step, or misunderstand the goal. So a useful brief includes a finish line. What should be true when the work is done? What must not be changed? When should it ask you instead of guessing? That is often more valuable than asking it to act like an expert.

A tool is a concrete action the agent can request. It might read calendar events, run a command, or save a draft entry. Those examples are different capabilities, not steps that must happen in that order. Without a tool, a chat model can describe a change. With an appropriate tool, the system may be able to make or inspect that change. But the word appropriate matters. A calendar-reading tool is not permission to read every calendar. A tool that writes a record is not a reason to submit unreviewed business data. The tool needs a clear interface, validation, and the right access boundaries. Start narrow. Read before writing. Use a draft or a small reversible change when you can. Start with review before consequential actions. Any later standing authorization must name the permitted category and boundaries; monitoring and human accountability remain. When an agent cannot do something, one useful question is: does it have a safe way to perform that action? Better prompting cannot create a capability or permission that is not there.

By harness, I mean the working environment around the model: instructions, tools, context, execution and controls. It is not one more tool the model calls; it is the environment that makes the work possible. Here is a concrete published example. LangChain reported improving its coding agent, deepagents-cli, from 52.8 to 66.5 percent on Terminal-Bench 2.0, using the same model label, GPT-5.2-Codex. That is a gain of 13.7 percentage points. The author says, “We only tweaked the harness and kept the model fixed, gpt-5.2-codex.” Their changes included verification guidance, environment context, reminders to reconsider repeated failed approaches, and reasoning allocation. This is not just changing a button or the colour of a chat window. There are limits to the comparison. These are the developer's reported results, not an experiment we reproduced. The benchmark suite is the same named suite, but the article does not establish byte-for-byte identical user prompts, a dated identical model snapshot, or equal compute budgets. The system instructions and execution strategy deliberately changed. This is not evidence that one named product always beats another, or that adding more agents always helps. The narrower point is useful: an agent's result belongs to the model and the system around it. When choosing a tool, ask not just which model it uses, but what context it provides, which actions it supports, how it checks work, and where you can stay in control.

Think of a CEO—the chief executive officer—working with a team. The main conversation should stay about the outcome, priorities, constraints and decisions that genuinely need the person's judgment. The CEO does not need every working message from every specialist. It is an analogy for keeping the human-facing thread useful, not for giving an AI executive authority. The orchestrator turns the goal into bounded work: what to do, what not to change, what success looks like, and what evidence to return. It follows through. If work stalls, it diagnoses the problem, changes an allowed approach, or asks for the missing human decision. A review can send a result back for correction before delivery. For a bigger, well-prepared job, a project-level coordinator can give a department or task coordinator an outcome, and that coordinator can organize specialists. Useful final handoffs include conclusions, artifacts, checks, uncertainties and decisions—not all the underlying conversations. None of this resumes magically. A runtime needs configured scheduling, notifications, persistence or another mechanism to continue after waiting or interruption. Those mechanisms, permissions and budgets must exist. Delegation is not correctness; it creates work to coordinate and check. For a small job, one agent using tools may be the simplest answer.

A designer might bring Photoshop, a clear design brief, and practice books or a style guide. Another specialist brings a different set of methods. An agent can be organized in a similar way: focused system instructions for its role, tools that fit the assignment, and reusable skills describing how our team approaches that work. Relevant tools mean relevance and least privilege—not a rule that designers can never use code or researchers can never make an image. Give the task the access it needs, not every capability in the company. A giant generalist loaded with every instruction, every tool and every transcript may have more irrelevant material competing for attention. A bounded assignment can reduce that pressure. It may also leave more room before the runtime has to summarize or compact context. That is a design rationale, not a universal benchmark result or a guarantee that compaction never happens. Separation is particularly useful for an independent check: ask a fresh reviewer to examine the actual result against the brief, not merely agree with the producer. Still, handoffs can lose information and extra agents cost time. Keep specialists only when their focus or independence helps. Return the accepted artifact, key evidence, remaining limits and decisions; don't force the main thread to read every specialist conversation.

We already introduced tools: ways an agent can act outside a conversation. MCP, the Model Context Protocol, is a common way for an AI application to connect to programs that expose those tools. Servers can also expose resources—context the application can read—and reusable prompt templates. We only need the tools-and-context idea today. For example, an agent app might ask a timesheet server which projects are available, then use the returned information in its work. That is an illustration of a useful read capability, not a claim about the exact tool names or features of our live server. An API is an Application Programming Interface: a defined way for software to interact with software. MCP is an API of sorts in that everyday sense, but it is not another name for any arbitrary web API. It is a particular protocol with shared conventions that compatible applications implement. A server can be a local process on the same computer or a service reached over a network. You don't have to learn the transport details to use the idea. Most importantly, connecting is not blanket permission. Authentication, authorization, consent and the application's own controls still need to be designed. MCP does not certify that the server is trustworthy or that its results are right. We have not verified the timesheet server's authentication or approval flow. Its website's access controls do not by themselves prove that the agent endpoint is protected. Examples across the MCP ecosystem (capabilities depend on the exact server, setup and permissions; no owner's accounts are connected or verified here): Gmail — Find and work with email. Google Drive — Find and work with files. Both share one COMMUNITY Google Workspace server: https://github.com/taylorwilsdon/google_workspace_mcp Calendly — Check availability and coordinate meetings. Community: https://github.com/meAmitPatil/calendly-mcp-server Lovable — Build and improve Lovable projects. Official hosted server: https://docs.lovable.dev/integrations/lovable-mcp-server and https://github.com/lovablelabs/mcp . Creation/messages may consume build credits; deployment creates a live URL whose access depends on workspace/website settings. Do not infer deployment authority from a connection. Docker — Inspect and manage containers. Community: https://github.com/ckreiling/mcp-server-docker . Engine access can change infrastructure. Playwright — Automate browser steps. Vendor: https://github.com/microsoft/playwright-mcp GitHub — Find code; work with issues and pull requests, subject to setup and permissions. Vendor: https://github.com/github/github-mcp-server HubSpot — Work with CRM contacts and deals. Official plugins use the hosted HubSpot MCP service: https://github.com/HubSpot/hubspot-mcp-plugins (HubSpot-Sales/.mcp.json identifies https://mcp.hubspot.com/anthropic). Sentry — Investigate errors and traces. Vendor: https://github.com/getsentry/toolkit and https://mcp.sentry.dev Notion — Find workspace knowledge. Vendor hosted Remote MCP: https://developers.notion.com/docs/mcp . The old self-hosted server is no longer maintained. Cloudflare — Inspect and manage cloud services. Vendor: https://github.com/cloudflare/mcp-server-cloudflare and https://github.com/cloudflare/mcp . Some tools change resources. Zendesk — Find support answers; work with tickets. Community: https://github.com/reminia/zendesk-mcp-server Obsidian — Search and update a knowledge vault. Community: https://github.com/MarkusPfundstein/mcp-obsidian . Runs locally through a community plugin and may change notes. Some servers are vendor-provided; others are community implementations. Logos identify examples, not endorsements. The privately packaged asset provenance records their source and rights limits.

Think about the end of a week or month. You are trying to reconstruct which projects and tasks you worked on, often from memory. The timesheet project combines an on-brand submission tool with an MCP server. The idea is to let personal agents help fill entries across projects and tasks using context they already have permission to access. Here is the workflow I recommend demonstrating: bring relevant context, suggest entries, then review and submit. We will confirm the live tool's exact steps rather than claiming this slide is a verified product flow. The agent can help with the blank page. It should not invent certainty. A calendar event might have been cancelled. Two events might overlap. A conversation can suggest a task without establishing how long it took. Project mappings can be ambiguous. That makes the human review valuable, not redundant. Resolve those gaps before committing business records. [Presenter cue: briefly explain the actual projects and tasks available in your demo. Use synthetic or explicitly cleared data. Tell the audience what the agent can access and what remains outside its scope.] The benefit we are illustrating is less manual reconstruction, not a measured time-saving percentage.

[Presenter cue: switch to the real timesheet tool and your personal agent. This deck does not contain or simulate that integration. Budget about five minutes.] I will use a small sample so we can inspect the result rather than watching a large batch run. First, here is the period and the context the agent is allowed to use. Here are the projects or tasks it needs to distinguish. I will ask for suggested entries and ask it to flag anything uncertain instead of filling gaps confidently. [Presenter cue: adapt that request to capabilities the tool actually supports. Show a tool call or result if it is available and safe to display.] Let us inspect one entry that looks well supported. What evidence connects it to the project? Now let us look at an uncertainty. This is where I correct the interpretation or supply missing information. Before committing anything, I review the proposed records. For a demonstration, prefer a sandbox or draft; do not submit real records just to make the demo feel complete. [Fallback cue: if the connection or authentication fails, stop retrying and describe the intended request, tool response, and review step. Use a prepared, cleared walkthrough if available. Do not present the deck's checklist as a working integration.] The point is the collaboration: useful context, a narrow tool, and a human decision.

The timesheet app is the workflow people use: choose a project, enter time, and review records. Three supporting parts do different jobs around it. Cloudflare hosting makes the app reachable. Hosting means delivering or running the app somewhere people can reach it, rather than leaving it only on the machine where it was built. That is the “serves the app” connection on the left. Cloudflare Access checks who may enter. It applies entry rules. Putting an office on a street and deciding who can come through its door are different jobs. Reachable does not mean open to everyone. SQLite keeps the timesheet records. The app reads saved entries and writes changes back: that connection goes both ways. Storage keeps entries available after the current interaction ends. Signing in does not prove that a project code is right, that time has not been counted twice, or that someone may change a particular record. The app still needs validation and action permissions, and people still review the work. Keep those responsibilities separate: reachable, allowed to enter, and correct records are three different questions.

You have been seeing another example throughout this talk: the presentation itself. We started with a local kit and a skill. The assistant read those instructions and asked about the audience, the goal, the length, the examples, and the boundaries. We then generated visual directions. I chose a cover, an introductory diagram, and pieces of several content templates. We refined those choices into one consistent shell, including the navigation and hidden sidebar. Only then did the implementation and content drafting begin. The result uses editable text and components. The generated abstract artwork is an asset behind the content, not a screenshot containing the whole slide. The tools also allow code checks and offline export checks. Those checks are useful, but they do not replace looking at the deck in a real browser, rehearsing the notes, or checking a real offline launch. We should describe only the checks actually completed. [Presenter cue: show the actual skill file, one selected concept image, or the editable deck source. Pick one artifact rather than turning this into a code tour.] My role was not to disappear. It was to provide context, choose a direction, and judge the result.

More autonomy does not transfer responsibility to the software. If I authorize a system to send messages, change records or act for the business, I remain responsible for how that authority is used. ‘My agent went rogue’ is not an excuse. Start by minimizing the actions, data and permissions involved. Reading approved documents is different from editing a customer account. Drafting a reply is different from sending it. Decide who owns the workflow, what it may do, what it must never do, and when it stops or asks for help. For a new or consequential action, approval before each item may be appropriate. Later, a clearly defined low-risk category might run without per-item approval, under an explicitly approved policy. That does not mean nobody checks anymore: we still need monitoring, spot checks, feedback and a person who can pause or narrow the automation. Uncertainty, conflicting sources, unusual requests and high-stakes situations need a route to a person. Customers and colleagues also need a usable way to reach humans and report mistakes. A model's confident tone is not evidence of correctness. Define the recovery step too: stop sending, preserve the relevant evidence, correct what can be corrected, and learn before widening the scope again. Which controls are appropriate depends on the real risk. More permission is not the starting point. A useful bounded task with a clear owner is. The genuine supplied exchange is an accountability example, not proof of the full incident facts, authorization, authenticity, jurisdiction or a criminal finding. Do not assert that a named person committed or admitted a felony. The labelled reply excerpt preserves the supplied pixels; View full supplied exchange opens the complete original (already cropped at the bottom when supplied). The reply describes agents doing signups/testing and a harness halted for reaching too far. It does not contain “oopsie”. Testing needs explicit authorized scope too. Stop when boundaries are crossed, preserve evidence, review and recover before continuing. Historical quotation, reproduced with its line break: A computer can never be held accountable Therefore a computer must never make a management decision IBM training material, 1979 — reproduced by Simon Willison: https://simonwillison.net/2025/Feb/3/a-computer-can-never-be-held-accountable/ Willison describes an internal training page, not primary IBM archival authentication or established company policy; the originals were reportedly lost and IBM archives could not locate a copy. Historical language is blunt: modern agents can perform bounded work, but humans own policy, permission and escalation decisions. A computer, by definition, cannot be held accountable for anything because there is no mechanism to hold it to account, short of turning off the electricity supply or destroying the hardware. Only humans can be accountable. — Mark Walport. Owner-provided exact transcription and source link: https://www.brainyquote.com/quotes/mark_walport_911450 . The page was not independently fetched successfully; do not claim otherwise. Both quotations illustrate responsibility, not a reason to reject later approved low-risk automation.

Customer support is a useful example because answering well is not just writing a friendly sentence. First understand the job. What are our SOPs—Standard Operating Procedures? What is the company policy? What does the customer need? Which wiki pages are current, and what is out of scope? Communication and systems thinking matter here. Strong coding skills are not a prerequisite for noticing the problem or describing good work. Next, practise on safe, realistic cases: approved or de-identified examples, with expected outcomes and difficult exceptions. Improve the prompts, reusable skills and context. Look for unsupported claims, wrong policy versions and cases that should be escalated. Passing those cases is useful evidence, not proof that all future cases will be right. There is an easy trap. If a human secretly chooses the perfect wiki paragraph every time, we have tested drafting from a curated paragraph—not the whole support task. If the intended automation must search, select sources and judge relevance, those decisions need to be included and checked too. Information in a retrieved page is evidence, not authority to change the system's rules. Write down what ‘good enough to try’ means for the bounded category: correct and current evidence, an appropriate response, no prohibited action, and escalation when needed. Do not connect a ticketing MCP server, say ‘good luck’, and assume the procedures will appear.

Once the whole task works well enough on safe examples, connect the plumbing deliberately. Start by automating information retrieval and drafting. RAG means Retrieval-Augmented Generation: finding relevant information and using it to help generate an answer. It is not necessarily retraining the model, and retrieving a page does not guarantee that the page or answer is correct. Check the sources selected and the draft produced. At this stage, a person approves every outgoing reply. Later, if evidence and the business owner justify it, allow auto-send for a narrow, low-risk category—for example, an approved factual question with a current source and no account change. Define the category and evidence requirements before launch. Cases outside it do not get forced through. Conflicting or missing information, sensitive account issues, material commitments and high-stakes situations go to a person. Don't rely on a confidence number alone. This is useful bounded full automation of an eligible task, not a claim that every support case should be automated. There is no per-item approval inside that approved boundary, but a human still owns the system. Keep spot checks, outcome monitoring, customer feedback and an easy route to human help. Start with a limited rollout; if failure patterns appear, pause sending or return to draft-only while correcting the cause. Agree suitable acceptance criteria with the workflow owner; this slide does not invent one universal error threshold or promise that finite testing guarantees future reliability.

Your first step does not need to be a big automation project. Notice something that happens again and again: reconstructing a week, finding a policy, preparing a recurring summary, or answering the same kind of question. Choose one task you understand well enough to judge. Write down the useful outcome, the context it should use, what is out of bounds, and how you will know it worked. That is communication and systems thinking. You do not need strong coding skills to begin. Technical help may be needed later for safe integrations, but it is not a reason to postpone understanding the work. Then refine the prompts, skills and context on safe examples. Check the awkward cases as well as the easy ones. Connect only the plumbing the next step needs: perhaps approved reading access first, then a draft, and only later a bounded action if it is justified. Finally, keep reviewing and improving. What did it miss? What caused the mistake? Does the task need better sources, clearer rules, a different boundary or human help? The goal is useful work, not maximum autonomy. If you take one practical exercise away, pick one small recurring annoyance and describe the finish line. Ask the agent to help with a plan, state the access boundary, and make the check explicit. That is enough to start learning without handing it your whole working life.