Leaf Lane
Toggle theme

Notes

Quick thoughts, interesting links, and short observations.

Start with the output, not the tool

Most AI adoption conversations start with tools. Which model should we use? Should we get enterprise access? Can we connect it to our CRM? These are reasonable questions, but they're the wrong starting point. The right starting point is the output: what, specifically, do you want to exist at the end of this process that doesn't exist now? This question forces clarity that tool-first thinking doesn't. "We want to use AI to improve our customer communications" is a strategy. "We want every support ticket response to have a draft generated before a human reviews it, so reviewers spend time on judgment calls rather than writing from scratch" is a spec. One of these can be turned into a workflow. The other can't. Starting with the output also helps you evaluate tools against actual requirements rather than feature lists. You're not asking "does this tool support integrations?" You're asking "can this tool produce a first-draft response to a support ticket, in our tone, using the ticket content and our knowledge base as inputs, in under 10 seconds?" Those are different questions, and the second one has a more useful answer. It also surfaces problems earlier. If you can't clearly describe what the output should look like, you don't have a workflow to build yet. You have a hypothesis to test. Testing it with an ad hoc prompt costs almost nothing. Testing it after you've bought three tools and hired a consultant to integrate them is expensive. The discipline of working backwards from desired output slows the conversation down at the beginning. It speeds everything else up.

The hidden cost of one-off AI requests

There's a pattern in most organizations that have started using AI tools: a handful of people are very good at getting useful outputs, and everyone else asks those people to do it for them. This feels productive. The outputs are good, the people asking are happy, and the AI-savvy person feels useful. But it's a bottleneck wearing a disguise. The problem isn't the individual requests. It's what doesn't happen when you handle AI as a service rather than a capability. The person making the request doesn't learn how to structure the problem. The person fulfilling it doesn't have time to build a reusable version. The output lives in an email thread or a Slack DM instead of somewhere the team can access it. And the next time a similar request comes in, the whole cycle repeats. One-off AI requests also tend to have higher failure rates than they look like on the surface. When a person translates a business need into an ad hoc prompt, they're making a lot of implicit decisions about what the AI needs to know. Some of those decisions are wrong. The output might be good enough that the requester accepts it, but not good enough that it would have passed a real quality check. The fix isn't to stop doing one-off requests. It's to build a habit of noticing when a request is the third or fourth version of the same thing, and treating that as a signal to build something repeatable instead. A documented workflow that five people can run independently is worth more than a hundred one-off requests handled by a single person. The one-off requests don't compound. The documented workflow does.

When to use Claude vs. GPT for a business task

The question comes up constantly, and the honest answer is: for most business tasks, it doesn't matter that much. Both models are capable, and the gap between them on any given task is usually smaller than the gap between a well-structured prompt and a poorly structured one. That said, there are genuine differences worth knowing about if you're choosing deliberately. Claude tends to do better with long documents. If you're summarizing a 50-page contract, analyzing a lengthy report, or working with a full email thread as context, Claude's extended context window and attention to the full document tend to produce more reliable results. It's less likely to lose track of content that appeared early in the input. GPT-4 integrates more easily with existing tools. OpenAI's ecosystem — plugins, assistants, function calling, integrations with Microsoft products — is more mature and more widely supported in third-party software. If your team is already in that ecosystem, staying there is often the pragmatic choice. Claude tends to refuse less and explain more when it declines. For business content that might touch sensitive topics — competitive analysis, policy drafts, legal language, HR communications — Claude is often more willing to engage with nuanced material and more likely to explain its reasoning when it can't. GPT-4 is often faster for short, well-defined tasks. For quick rewrites, translation, code snippets, or structured data extraction where the context is minimal, GPT-4 responds quickly and accurately. The real answer to "which should I use" is: try both on your specific task with your specific inputs, and pick the one that produces better output. Then document that decision so your team doesn't have to make it again from scratch.

What makes a good AI workflow spec

When teams first start building AI workflows, they jump straight to tools and prompts. The result is usually something that works for the person who built it and no one else. A spec — a written description of what the workflow is supposed to do — changes this. It's the difference between a workflow that can be reviewed, improved, and handed off, versus one that lives inside a browser tab that only one person understands. Here's what a useful AI workflow spec actually contains. Purpose. One or two sentences describing what this workflow does and why it exists. This isn't filler — it's the thing you return to when something breaks or when someone asks whether to use this workflow for a related task. Trigger. What event or condition starts the workflow? A form submission, a new row in a spreadsheet, a Slack message, a human decision point? Be specific. "When we need it" is not a trigger. Inputs. What does the workflow need to run? List every required input and what format it should be in. If an input is optional, say so. This is what you're feeding the AI, and inconsistency here is the most common source of inconsistent output. The AI step. What exactly is the AI being asked to do? Include the prompt or a reference to where it's stored. Note any constraints: word count, format, tone, things to avoid. Output. What does the result look like? Where does it go? Who sees it first? If there's a review or approval step, that belongs here. Edge cases and failure modes. What should happen if an input is missing or malformed? What does a bad output look like, and what's the fallback? A spec doesn't have to be long. A one-page document that answers these questions will save hours of confusion down the line.

How to QA an AI output before trusting it

AI tools produce output fast. That speed is valuable, but it creates a risk: the faster something arrives, the easier it is to skip the review step. Here's a practical quality assurance approach that works regardless of what the AI is producing — written content, summaries, data extractions, draft emails, or structured reports. Check for hallucinations on verifiable claims. If the output includes specific facts, numbers, names, or dates, verify at least a sample of them. AI models are confident even when wrong. A claim being stated clearly is not evidence it's true. Compare to your brief, not to your expectations. It's easy to unconsciously adjust your mental model of what you asked for to match what you received. Go back to the original input or prompt and verify the output actually addresses what was requested — not a reasonable interpretation of it. Read it aloud, or have someone else read it. This is low-tech but reliable. Reading silently lets your brain autocorrect awkward phrasing. Reading aloud forces you to process every word. You'll catch more. Check the structure, not just the content. Is the output formatted the way you specified? Are headings where they should be? Did it actually fill in every field you asked for? AI outputs often have correct content but wrong structure, especially with longer or more complex tasks. Test edge cases if it's going into a system. If the AI output feeds into another tool or workflow, manually run a few edge cases before automating. What happens if the input is unusually short, unusually long, or written in a different format? A five-minute QA check on an AI output is faster than cleaning up a mistake after it's already downstream. Build the habit early.

The difference between a prompt and a process

A lot of teams think they're building AI workflows when they're actually just writing better prompts. These are different things, and confusing them creates a ceiling on what you can actually accomplish. A prompt is a single instruction to an AI model. It can be detailed, well-structured, and highly effective. But it's still one input, one output. If the human running it leaves, or if the context changes slightly, the result changes too. A process is a repeatable system. It has defined inputs, defined steps, defined outputs, and clear handoffs. It doesn't depend on any one person knowing the right magic words. It works the same way on Tuesday as it does on Friday. When AI gets embedded in a real process, a few things need to be true. The trigger for running it has to be clearly defined — not "when someone remembers to use it." The inputs have to be consistent — not "whatever the person types in." The output has to feed into something — a document, a CRM field, a review step — not just a chat window. Prompts are a starting point. Most teams discover a good prompt and stop there. That's fine for individual productivity. But if you want something your whole team can rely on, something that runs without constant babysitting, you need to graduate from prompts to processes. The upgrade usually involves three things: documentation of when and how to trigger it, a structured input format so the AI gets consistent context, and a defined output format that integrates into your existing tools. A prompt is something you write once. A process is something you build and maintain. The distinction matters if you're serious about scale.

3 signs your team is not ready to automate a workflow

Before you hand a workflow to an AI tool, you need to be honest about whether that workflow is actually ready. Most failed automation attempts don't fail because the AI wasn't good enough. They fail because the team handed over a process that was already broken, undocumented, or inconsistently executed. Here are three warning signs to check before you start building. The process works differently depending on who's doing it. If two team members complete the same task in significantly different ways — and both are considered "correct" — you don't have a process yet. You have a pattern. AI tools need consistency to learn from. If your human team can't agree on the steps, the AI won't either. There's no way to measure output quality. "It just has to be good" isn't a quality standard. Before automating, you need a clear definition of what done looks like. This means specific criteria: the right length, the right format, the right tone, the right data fields filled in. Without that, you can't tell if the AI is doing well, and you can't improve it when it isn't. The last time you documented this process was never. If the workflow only lives in someone's head, you're not ready to automate it — you're barely ready to delegate it to another human. The first step is to write it down. That exercise alone often reveals gaps, redundancies, and edge cases you didn't know existed. Automation amplifies whatever is already there. A clean, consistent, well-defined process becomes faster and more scalable. A messy one just fails faster at scale. Do the prep work first. The automation part is actually the easy part.

Get practical AI workflow tips, weekly

Short, tactical ideas you can apply immediately.