Notes from a room of AI power users

At our October 22 Rebuild seminar, the third session in The Triptych Sessions leadership series, we brought a slide deck about tools, prompts, and team workflows. We spent most of the session comparing notes.

Around the table were people using AI for very different kinds of work: consolidating spreadsheets, developing brand content, preparing sermons, managing projects, and building software. Some were working entirely in chat. Others had persistent agents coordinating tasks across computers and applications.

The conversation kept coming back to the same practical questions. Where does AI actually save effort? How do you preserve the judgment behind the work? And when does building a system become one more thing standing between you and the task?

Getting a useful answer from AI can happen in a few minutes. Building a dependable workflow requires clear inputs, shared context, a way to judge quality, and someone responsible for the result. This is where much of the opportunity sits for organizations moving beyond individual experimentation.

The examples below come from that discussion, with practical ways to apply them and a few operating principles from the Rebuild deck.

Three levels of adoption

Our conversation kept returning to three ways people use AI.

At the first level, it acts like an expanded search tool. People ask questions, explore unfamiliar subjects, and get explanations. This can be helpful, provided they check claims that matter.

At the second level, people use AI to do parts of their work: draft a message, organize notes, review a proposal, write code, or prepare for a meeting. An individual develops habits and learns which context produces useful results.

The third level changes how work moves through an organization. Information is captured consistently. Tasks have defined handoffs. AI prepares something another person or system can use. Review becomes part of the process.

That third level is harder because it involves people, responsibilities, and existing habits. A workflow that saves one person an hour can still create problems if it sends incomplete information to the next person.

Before choosing a tool, describe the work. What starts it? What information does it need? Who uses the result? Where does judgment enter? What happens when something is missing?

Those questions give an AI implementation something concrete to improve.

Start with ordinary work

One participant described bringing information from ten differently formatted spreadsheets into a single consistent spreadsheet. Previously, that meant rearranging columns, unmerging cells, and stripping out formatting before the information could be used.

They were doing this through chat, without a persistent agent or an elaborate automation. The value came from removing tedious preparation from an existing task.

For a similar task, define the destination before asking AI to transform the sources: column names, what each field means, how dates should appear, and what to do with missing or conflicting values. Review a sample and reconcile the result against the source files.

A starter prompt might be:

Map these source spreadsheets into the attached destination structure. Preserve source values, flag ambiguous matches, and report any rows you cannot place confidently. Do not infer missing information. Show the mapping for review before transforming the full set.

A successful first integration might simply give someone a cleaner starting point for work they already know how to do.

Context in useful layers

One of the most practical ideas shared in the room concerned brand guidelines.

It is tempting to give AI every rule at the beginning: audience definitions, positioning, writing style, prohibited words, formatting requirements, examples, exceptions. Then we ask it to think strategically, generate ideas, write, and edit in the same pass. As one participant put it:

“It’s trying to follow all the rules at the expense of creativity.”

A more manageable approach is to deliver context as the work needs it.

During planning, provide the audience, objective, and central idea. During drafting, add voice guidance and representative examples. During editing, introduce detailed checks for terminology, formatting, and publication requirements.

For a blog post, that might look like this:

1. Plan: Identify the reader’s problem and propose an outline using the source material.
2. Draft: Write from the approved outline using a few strong examples of the organization’s voice.
3. Review: Check accuracy, audience fit, unsupported claims, and brand requirements.
4. Finish: Prepare the headline, excerpt, links, and other publishing details.

Each phase has a clear job and a visible result. If something goes wrong, you have a better chance of seeing where it happened.

This also helps separate different kinds of context. A past article can demonstrate sentence rhythm without becoming a factual source. A brand guide can establish tone without answering a technical question. Tell the model what each reference is there to do.

Give critique a purpose

Another useful pattern is to ask AI to review work from a particular perspective.

A prospective customer might question whether a proposal explains the value clearly. An internal stakeholder might notice an unrealistic handoff. A UX writer might identify instructions that leave a user unsure what to do next.

These simulated perspectives can reveal questions you have overlooked. They are hypotheses to test with real people, especially when the decision depends on customer research or specialized expertise.

The review prompt matters. “Make this better” leaves the model to invent its own standard. It can also encourage revision for revision’s sake.

One participant described returning another AI’s critique to the original assistant with a specific instruction:

“Your job is to triage it. It could be wrong. Ignore is a valid option.”

That permission to reject a suggestion helps make review a decision rather than an automatic rewrite.

For example:

The following critique came from another AI, not from me. Review it against the full proposal and the original brief. For each suggestion, recommend accept, modify, or ignore and explain why. Ignore is a valid option. Show proposed changes in the context of the surrounding passage so I can judge their effect.

The surrounding context matters. A sentence can look weak in isolation while doing an important job in a paragraph. Ask to see edits in place, then decide whether they improve the work. A second model can catch a missed issue, but it can also introduce a new one.

Repetition improves the workflow

One participant described a weekly sermon preparation routine. They dictate a stream of thoughts, then use Claude to organize and clarify the material.

The arrangement depends on a specific boundary: during the initial capture, the assistant should acknowledge the input and wait until it is explicitly invited to respond. Premature organization interrupts the thinking the workflow is supposed to support.

Another instruction separates style from substance: borrow rhetoric, grammar, and speaking style from past sermons, but do not import theology from them into the current sermon. The participant described the model blending ideas that were close in wording but meaningfully different: “It’s like smoothing out the edges and then bringing stuff over. And I’m like, ‘That’s close, but not right.’”

That distinction applies well beyond this example. An organization might want AI to borrow the structure of an old proposal without reusing its pricing, or match the voice of a past article without repeating its conclusions.

The participant also described recent output becoming more generic. They were experimenting with newer examples and giving those examples more weight. The cause was uncertain; a model change, accumulated instructions, or the reference material itself could all warrant investigation.

The useful lesson is to treat an established workflow as something you maintain. Keep examples current. Remove instructions that no longer serve a purpose. When quality shifts, compare the output against a saved example before changing everything at once.

The participant still spent hours writing, revising, and editing. The reported benefit was clearer organization and less stress around the task. A recurring workflow can be valuable without removing the demanding human work at its center.

Choose models through experience

The room had preferences about Claude and ChatGPT. Some participants favored Claude for organizational thinking and working with project context. One described turning to ChatGPT when they wanted “a really robust thesaurus to dance with.” Others had different preferences for different parts of the same task.

These were experiences with particular tasks and setups. They offer useful starting points for experimentation, rather than a permanent ranking.

A model’s usefulness depends on the material you give it, the instructions surrounding it, and what you want back. A strong planning partner may need more direction to write in your voice. A fluent writer may need closer review when extracting exact facts.

Save a few representative tasks and rerun them when you are considering a model change. Include the awkward cases: incomplete notes, conflicting instructions, and examples where a previous answer sounded good but missed the point.

Your actual work is a more useful test than a general impression of which model is winning this week.

Build your own benchmark

The group discussed a limitation of public benchmarks: a score cannot tell you whether a model can do your particular job well. Familiarity with benchmark tasks can also complicate what those scores mean.

A simple internal evaluation starts with a rubric defined before you look at the answers.

For a LinkedIn post, for example:

Give three or four models the same source material and brief. Label the outputs anonymously before reviewing them. Score them against the rubric, and record why one result is more useful.

For an editorial test, factual accuracy can be a pass-or-fail requirement, with the remaining criteria scored from one to five. This keeps a polished but inaccurate response from winning on style.

AI can help with an initial evaluation, especially for classification or format checks. Have a person make the final call when taste, meaning, or consequences matter. If an AI scores the outputs, hide their model identities from it too and check its judgments against human reviews.

The goal is to choose a model and process that reduce the total effort required to produce work you trust.

One participant also described matching a text message from a construction site to the correct stage of a build. They had experimented with a specialized judgment model for that classification step.

That is a different job from writing a good proposal. You can evaluate whether a message was assigned to the right stage, record mistakes, and define when uncertainty should trigger review. Some workflow steps need nuanced writing; others need a reliable match among a few known options. Test each step according to its job.

Agents need clear handoffs

Persistent agents were another major topic. One participant described a hosted setup with narrow roles: scouting relevant business communities, writing, and monitoring selected email. A coordinating agent could help propose a team and divide up a new project.

Another participant described running Hermes on a Mac, with remote access through Tailscale, an orchestrator managing a Kanban board, and agents assigned to coding, design, and copywriting. Different roles could use different models. A less expensive model handled rough copy drafts, with final writing treated as a separate job.

The interesting part was the division of responsibility. Someone or something assigned the work, tracked its state, and made the next step visible.

That structure is worth examining before adding agents. For each role, define:

• The task it owns and the information it can access.
• The output it must produce and who receives it.
• The actions it may take independently.
• The uncertainty or failure that requires a person.
• The condition that means its work is complete.

An agent that researches competitors could produce a dated brief with source links. A writing agent could draft from that approved brief. A review agent could check the draft against the brief and a specific rubric.

More agents create more handoffs to manage. Start with the smallest arrangement that helps, and keep the state of the work visible.

The group also raised a practical cost issue: usage limits can discourage experimentation before someone learns what a workflow can do. Set a bounded testing budget and track cost per completed task. Leave enough room to test representative work, including failures, before deciding whether the system earns its ongoing cost.

Make memory explicit

The discussion of agents also surfaced a more familiar problem: returning to a project and trying to remember what happened.

One approach shared in the session used deliberate start and end routines, supported by custom instructions and skills. At the beginning, the agent reads project context. At the end, it records decisions, unfinished work, and the next action. Obsidian notes and a shared Git repository helped carry that context across sessions and collaborators.

You can use this pattern in an ordinary chat before building a more elaborate system.

A useful closing instruction is:

Summarize the current objective, decisions made, files or sources used, unresolved questions, and next action. Separate confirmed decisions from suggestions. Include enough context for another person or a new session to continue.

Store that summary somewhere the team can find it. Review it before treating it as authoritative, and update it when decisions change.

A good handoff preserves the state of the work. It should tell the next person what is ready, what is uncertain, and what needs to happen next.

The benefit was also personal. The participant described keeping sessions open for weeks because closing them felt like losing hard-won context. A deliberate wrap-up created permission to stop, even when the work was unfinished. “That mentality is just as much for me as it is for the agent,” they explained. The next session had a defined place to begin.

Prototype before automating

Several conversations pointed toward the same advice: work through a process manually before turning it into an automation.

One participant described prototyping a sequence of prompts inside chat, moving through the workflow one step at a time. Saving those intermediate states made it easier to see how the information changed and where a problem entered.

You can apply this to a client update: extract decisions from meeting notes, identify open questions, draft the message, then review it. Keep the result of each stage. You may discover that the notes never distinguished a suggestion from a commitment, or that the draft needs information nobody captured.

Once the steps work, decide which ones benefit from automation.

A more involved example came from a participant turning raw job-site video into social content. The person recording the footage wanted a simple place to drop files. The person responsible for customer-facing communication wanted a list of posts to approve.

Between those two people were several steps: ingesting footage, transcription, captions, and preparation for review. The workflow needed to serve both ends. Asking the person on site to manage the publishing process would have defeated much of its purpose.

The group discussed Zapier, Make, and n8n as ways to connect systems. Participants associated Zapier with straightforward sequences and Make with branching flows and inspecting information at each step. n8n was also on the group’s radar, though less explored in the conversation. Zapier also provides AI agent tooling for tasks involving connected applications.

Across platforms, the shared frustration was fragile chains. One step returns an unexpected format, and the downstream process breaks or uses the wrong information.

Define the handoff between each step. Participants described failures caused by assumptions about what an application’s API would accept or return. Inspect representative payloads, which are the actual data passed between systems, and test the required fields and formats. If a downstream step needs a date, owner, and status, validate them before passing the work along.

Add limited retries where they help, a visible failure log, and a route to a person when the process cannot recover. For a workflow connecting three or four tools, the ability to inspect a failed handoff can matter more than an impressive agent demo.

Some participants had moved parts of these workflows into small custom tools built with coding assistants. Others valued visual automation platforms because the branches and intermediate data were easy to inspect. Compare the ongoing maintenance burden, the systems being connected, and who will troubleshoot the result.

Document before changing roles

Organizational adoption was one of the harder subjects in the room.

One nonprofit leader described building a system to help a development colleague keep donor relationships in view: regular check-ins, follow-ups, and appropriate fundraising conversations. But the stream of new systems and improvement ideas was costing the team momentum:

“They’re spending more time building a system than executing anything in it.”

The leader had scaled back some experiments to return attention to the work itself. Asked how they decided when a system was good enough, they answered candidly: “It doesn’t seem good enough yet. And rather than working more on it … I gotta do the work.”

People who are already at capacity may experience an AI initiative as additional work: learn a tool, explain their process, check unfamiliar output, and keep everything else moving. As another participant observed, “They want AI to be that relief valve, but it takes a lot of work to do it.”

A useful starting point is documentation that helps immediately. One participant framed this as capturing the logic, judgment, and edge cases that keep a business dependent on its owner. Recording a sequence of steps is only part of that job; the difficult part is understanding why an experienced person chooses one path over another.

This creates onboarding and reference value while making potential automation easier to assess. Earlier in the conversation, the nonprofit leader had described using AI to organize institutional knowledge for new team members:

“How do I reduce three decades of insight into a 15-minute nugget?”

That is an immediately useful goal, even before any part of the process is automated.

A workflow card can stay brief:

Use that card to walk through real scenarios with the person who knows the work. One approach discussed in the room was to have AI simulate cases, surface assumptions, and return a short list of questions for the expert to confirm, reject, or adjust. Then rerun the scenarios. Treat this as a method to test and refine, with the expert’s corrections becoming part of the documentation.

The group’s “gym fallacy” analogy captured another trap: “You have the weights right next to your bed and you’re still not using them.” In the same way, making an AI system easier to access does not guarantee that the underlying work will happen. Sometimes the useful decision is to stop configuring and do the task.

Keep the first experiment small enough to finish. A working process with a few rough edges gives you something useful to improve.

Adoption can also be gradual. Let someone move through the process manually, automate a familiar section, or use a hybrid approach according to the task’s complexity. A single leap from an established routine to full automation may ask for more trust than the team has had a chance to build.

Separate judgment from rules

A manufacturing handoff discussed during the session illustrated why workflow analysis matters. Design and production teams used different tools, and geometry created in one environment needed reworking for the other. The opportunity was to examine the conversion between them.

Some parts of a process are deterministic: given the same inputs and rules, they should produce the same result. Other parts involve incomplete information, interpretation, or a consequential judgment call.

Map that distinction before deciding where AI belongs. A geometry conversion with defined requirements may call for conventional software and validation. An assistant could help explain an exception or gather missing information. A person may still need to approve the result.

AI can help build a tool without needing to make every decision inside that tool. For many organizations, integration will involve a mix of ordinary software, AI assistance, and human review.

Local AI has tradeoffs

The group explored both running agents on local computers and running models on local hardware. Those are separate choices.

An agent can run on a Mac while sending requests to a cloud model, as in the Hermes setup discussed earlier. Local inference means the model itself processes requests on your hardware. LM Studio, for example, supports running downloaded models and working with documents offline.

For a local model, the economics include hardware, electricity, setup, maintenance, and review time. For a locally hosted agent using cloud models, provider usage costs still apply. External tools and integrations can also send information beyond the machine.

Start with a narrow task and representative inputs. Measure accuracy and speed on the hardware you have. Check the model’s license and trace where the complete workflow sends data.

Extraction, classification, and internal drafting may be useful candidates to test. The right question is whether a particular local setup meets your requirements at a reasonable total cost.

One participant working in health insurance raised a more immediate concern: they wanted administrative help without granting broad access to sensitive customer information. That is a useful starting constraint. Identify tasks that can be tested using public or synthetic inputs, then assess the complete data path before introducing real sensitive information. Local processing is one architectural choice, rather than a complete answer to access, retention, or compliance requirements.

Put review where it matters

The deck offered a useful framework for deciding how much autonomy a workflow should have:

For early implementations, drafting with approval is often a useful place to begin. It gives the team real output to evaluate while keeping a person responsible for what ships.

Choose tools according to the information they will handle. Review access, retention, and data-use settings, including for AI features inside software you already use. Give each workflow an owner and make it possible to pause when results become unreliable.

The broader conversation about automation and displacement reinforced this point: organizations need to decide who is accountable when a system acts. That decision belongs in the workflow before autonomy expands.

Measure the whole task

A fast first draft can still be expensive if someone spends an hour correcting it.

The deck suggested three measures: cycle time, edit rate, and hours returned. Together, they offer a practical view of whether a workflow helps.

Measure the time from request to approved result. Track how much the reviewer changes, especially factual corrections and repeated structural problems. Account for setup, supervision, and maintenance when estimating time saved.

Also record cost per completed task, including failed runs. A cheaper model that needs several attempts may cost more overall.

Keep a small shared library of working prompts, with an owner, a version, and an example of acceptable output. When a reviewer repeatedly fixes the same issue, update the workflow or its context. That turns individual editing effort into a team improvement.

A practical 90-day plan

You can begin with one recurring task and a person who understands it well.

This week: Choose the task, name its owner, and document the current process. Save a few representative examples and establish the time and quality baseline.

This month: Prototype the steps in chat. Define the rubric, test models anonymously, and record what the reviewer keeps changing. Store the workflow card, prompt, and approved example together.

This quarter: Automate the steps that have proved dependable. Add validation at handoffs, a clear exception path, and the appropriate approval points. Review cycle time, editing effort, and cost before expanding.

Keep the routine light: a short weekly review of exceptions, a monthly look at results, and a quarterly decision about which tools to keep, change, or retire.

Rebuild gave us a room full of different experiments, preferences, and unresolved questions. It also gave us a useful direction: make the work visible, test it on real examples, and improve it with the people who understand it.

At Triptych, we bring strategy, design, and development together to work through those questions. If your team is ready to turn a promising AI experiment into a process people can use, let’s talk about where to begin.

Further reading

• LM Studio offline operation
• Zapier agent building documentation