# How Does TryUncle Work? Inside the Screen-to-Answer Loop

> **Quick answer:** TryUncle's Uncle takes a screenshot and reads DaVinci Resolve's on-screen control map through macOS Accessibility, sends both plus your question to cloud AI providers (Gemini, Anthropic, OpenAI), then speaks back an answer while drawing a box, a circle, or flying a cursor to the exact control on your own screen, live.

*Published by [TryUncle](https://tryuncle.com) — the AI tutor that teaches DaVinci Resolve on your own screen.*
*Updated 2026-07-13 · TryUncle founder pricing, first 100 seats (July 2026) · Canonical: https://tryuncle.com/learn/davinci-resolve/how-does-tryuncle-work*

You already know the marketing line: Uncle watches your screen and points at the control. What you're actually asking is how. What gets captured, where it goes, which AI answers you, and why the box appears exactly where it does instead of three menus over. Fair question. Here's the mechanism, piece by piece, from the moment your finger hits a keyboard shortcut to the moment a cursor lands on the right slider.

This isn't a sales page. It's an engineering walkthrough, built from TryUncle's own FAQ and privacy policy, and from the public technical documentation for the macOS frameworks a screen-reading, screen-pointing app has to be built on. Where TryUncle hasn't published a detail, this guide says so instead of guessing.

## What Happens, Step by Step, When You Ask Uncle a Question?

Start here, because everything else in this guide is a zoomed-in look at one of these steps.

| Step | What happens | Where it happens |
| --- | --- | --- |
| 1. You press a shortcut | Shift+Fn to talk, Shift+Control to check your current work, or Shift+Option to type | On your Mac |
| 2. Uncle takes a screenshot | A screenshot of the active window or connected displays, captured at that instant | On your Mac, via macOS Screen Recording |
| 3. Uncle reads the control map | Labels, roles, and positions of visible controls, read through macOS Accessibility | On your Mac |
| 4. Your question gets attached | Voice is transcribed to text, or your typed text is used directly, or Check runs with no typed question at all | On your Mac, then sent out |
| 5. Everything goes to the cloud | The screenshot, the accessibility data, and your question are sent to Uncle's AI providers | Cloud, over your internet connection |
| 6. The model reasons about your screen | The AI answers your specific question about your specific project, and identifies the target control | Cloud |
| 7. Uncle speaks or displays the answer | A spoken reply generated by a text-to-speech provider, or written text if you typed | On your Mac |
| 8. Uncle draws the pointer | A hand-drawn box or circle, a flying cursor, or a short looping demo for drag moves | On your Mac, on top of DaVinci Resolve |

Two things about that table matter more than the individual rows. First, steps 2 and 3 happen locally and instantly, before anything leaves your Mac. Second, steps 5 and 6 are the only part of the loop that requires the internet, and they're also the part where the actual "intelligence" lives. Uncle isn't running a large model on your laptop. It's running a very fast local capture step, followed by a cloud reasoning step, followed by a local rendering step. That architecture explains almost every constraint covered later in this guide: why Uncle needs to be online, why it needs two separate permissions instead of one, and why a screenshot briefly touches several outside companies on its way to becoming a drawn box on your screen.

**Uncle never runs a large AI model on your Mac. Every question is answered in the cloud and the result is drawn back onto your screen locally.** That single fact is the shape of the whole product, and it's worth holding onto as you read the rest of this guide.

## What Is Uncle Actually "Seeing" When It Watches Your Screen?

"Watches your screen" sounds like continuous video, the way a screen-sharing call works. It isn't. According to TryUncle's own FAQ, data collection happens only "when you ask a question," with the company stating plainly that there is "no background recording, no always-on listening, and no continuous screen monitoring" (source: TryUncle's privacy policy). What Uncle takes is a single still image, a screenshot, captured at the exact moment you press Shift+Fn, Shift+Control, or Shift+Option.

On a Mac, that screenshot is almost certainly captured through Apple's own screen capture framework, ScreenCaptureKit, the API Apple built specifically for apps that need to see all or part of a user's screen for legitimate reasons like screen sharing, streaming, and content creation (source: developer.apple.com/documentation/screencapturekit). ScreenCaptureKit didn't exist by accident. Apple built it to replace older, less controlled capture methods, and gated it behind an explicit privacy setting from day one. Ernest, a software engineer on the ScreenCaptureKit team, described the design goal at Apple's WWDC22 session introducing it: "The framework will require consent before capturing video and audio content, and the choice will be stored in the Screen Recording privacy setting in system preferences" (source: developer.apple.com/videos/play/wwdc2022/10156/). That's the same privacy setting you grant Uncle access to during setup, the one labeled Screen Recording in System Settings.

That single toggle is powerful and blunt at the same time. Powerful, because once granted, an app using ScreenCaptureKit can capture at "high quality and performance up to the native resolution and frame rate of your display" (source: developer.apple.com/videos/play/wwdc2022/10156/), meaning Uncle isn't working from a blurry, downsampled thumbnail of your Color page, it's working from a full-fidelity image of your actual node tree, your actual waveform, your actual color wheels. Blunt, because the permission itself doesn't distinguish between "capture continuously" and "capture once, on demand." That distinction lives entirely in how TryUncle chooses to call the API, not in what macOS enforces at the permission level. Which means the "we only capture when you ask" commitment is a policy choice TryUncle has made and published, not a technical limit macOS imposes on it. Worth knowing if you're deciding how much to trust that commitment.

What a screenshot alone gives Uncle is a picture. A flat grid of pixels, no different in kind from a photo you'd text a friend. A picture tells you what the Color page looks like. It doesn't tell you, on its own, which exact pixel range is the saturation slider versus the contrast slider, or where one qualifier's soft-edge control ends and the next control begins. For that, Uncle needs a second, completely different kind of data, and that's the part almost nobody outside of accessibility tooling knows exists.

## How Does Uncle Know Where to Point?

This is the part that actually makes Uncle different from "take a screenshot and ask a chatbot about it," which is a workflow you could already build yourself with any multimodal AI and five minutes of copy-pasting.

macOS ships with a second framework most users never think about, called the Accessibility API, built around a data structure called AXUIElement. It exists so that screen readers, like VoiceOver, and other assistive technologies can describe an app's interface to someone who can't see the pixels at all. Every button, slider, menu, and label that a well-built Mac app exposes gets a corresponding accessibility object, and Apple's own documentation describes AXUIElement as the structure used to refer to that object (source: developer.apple.com/documentation/applicationservices/axuielement). Crucially, that object carries structured data, not pixels: a role ("slider"), a label ("Saturation"), a value, and a position on screen, retrievable through calls like the one that returns the accessibility element sitting at a specific screen coordinate.

That's the map. A screenshot tells Uncle what the Color page looks like. The accessibility tree tells Uncle that the thing at coordinate (840, 412) is specifically labeled "Saturation" and has the role "slider." Put the two together and Uncle isn't guessing where the saturation control probably is based on visual pattern-matching against a picture. It's reading an exact, structured coordinate handed to it directly by the operating system.

There's a practical reason this matters beyond precision: speed. Reading an accessibility tree is a fundamentally lighter operation than analyzing an image. One developer analysis of building macOS AI agents put a single accessibility-tree read at around 50 milliseconds, describing it as 40 to 100 times faster than a comparable screenshot-analysis pass, which it estimated at 2 to 5 seconds per frame (source: fazm.ai/blog/macos-ai-agent). Treat that specific multiple as one developer's own estimate rather than an audited benchmark, since the source itself doesn't cite an external study, and TryUncle hasn't published its own measured numbers. But the underlying mechanism it's describing, structured coordinate data versus pixel analysis, is real and well documented, and it's exactly the gap between what Screen Recording alone can give an app and what Accessibility adds on top of it.

**A screenshot shows Uncle what your interface looks like. The Accessibility API tells it exactly where every control actually is.** Those are two different kinds of information, gathered through two completely different macOS permissions, and Uncle needs both to do what it does.

## Why Does Uncle Need Two Separate Permissions Instead of One?

This is the single most common source of first-run confusion with TryUncle, and understanding the mechanism explains exactly why it happens.

| Permission | What it gives Uncle | What breaks without it |
| --- | --- | --- |
| Screen Recording | A picture of your screen | Uncle can't see your project at all, so it can't answer anything |
| Accessibility | The exact coordinates and labels of every visible control | Uncle can still talk, since it has the picture, but it can't draw a box or move a cursor to a specific spot, because it has no map to point with |
| Microphone (optional) | Your spoken voice, converted to text | You lose Talk (Shift+Fn); Check and Type still work fully |

Grant only Screen Recording, and Uncle behaves like a chatbot you've pasted a screenshot into. It can look at the picture and describe, in words, roughly where something is: "it's the third slider down in the Color Warper panel." What it can't do is draw a box around that exact slider or fly a cursor to it, because drawing on screen requires a real coordinate, and a coordinate is exactly what a flat image doesn't hand over on its own. This is the mechanical reason Accessibility exists as a separate, second permission rather than being bundled automatically with Screen Recording. macOS treats them as distinct risk categories, because they expose genuinely different kinds of information: one shows what's on screen, the other exposes what every visible control is and does, which is a meaningfully deeper level of access into how an app is built and used.

That separation isn't a TryUncle design quirk. It's a macOS-wide pattern. Any app that wants to both see your screen and interact intelligently with what it sees, a remote-support tool, an automation script, an accessibility utility, hits the same two-permission wall, because Apple built the operating system to make each type of access an explicit, separately revocable choice. If you've ever used a remote IT support tool that could see your screen but couldn't click anything for you until you granted a second permission, you've already experienced this exact split from the other side.

One detail worth being precise about, since it's easy to get backwards: Accessibility on its own doesn't give Uncle a picture. It gives structured data about controls, roles, labels, positions, without any visual context around them. Screen Recording is what gives Uncle the picture. Uncle needs Screen Recording to understand what's happening on your screen in the first place, and it needs Accessibility on top of that to translate "the thing that's wrong is right there" into an actual coordinate it can draw on.

## What Happens After You Ask: How Does the Cloud Reasoning Actually Work?

Once the screenshot, the accessibility data, and your question leave your Mac, they don't go to one single AI model. According to TryUncle's own privacy policy, the request is routed across a handful of specialized third-party providers, each doing a different piece of the job (source: TryUncle's privacy policy):

| Provider | Role in the loop |
| --- | --- |
| Google (Gemini) | Core assistant reasoning, understanding your question and your screen together |
| Anthropic | Visual pointing precision |
| OpenAI | Fallback speech-to-text and visual pointing |
| AssemblyAI | Speech transcription for voice questions |
| ElevenLabs | Text-to-speech, generating Uncle's spoken reply |
| Supabase | Account and storage management |
| Cloudflare | Proxy hosting |
| Whop | Subscription billing |
| PostHog | Aggregate usage analytics only |

Two things stand out about that list. First, no single company handles the entire loop. Reasoning and pointing precision run through more than one model provider, which reads less like a single off-the-shelf integration and more like a deliberate choice to use whichever provider is strongest at a given sub-task, reasoning here, pixel-level pointing there, with a fallback provider named explicitly for both speech-to-text and pointing in case the primary one fails or underperforms on a given request. Second, this is genuinely more infrastructure than a lot of AI products expose, and it's worth naming plainly rather than glossing over: your screenshot briefly passes through several outside companies before it comes back as a spoken answer and a drawn box.

Why not just use one model for everything? This guide can't read TryUncle's internal reasoning, since that level of product decision-making isn't published anywhere public. But the general pattern it's following is a well-established one in the wider AI industry: different foundation models measurably outperform each other on different narrow tasks, general reasoning versus precise visual grounding versus natural-sounding speech synthesis, and a product built for reliability tends to pick the strongest available model per task rather than accept the weakest link of a single, do-everything model. Anthropic's own account of training Claude for computer use describes visual pointing specifically as something that required dedicated attention: the model had to learn "how many pixels vertically or horizontally it needs to move a cursor in order to click in the correct place," and Anthropic notes that getting this precise was harder, and more important, than it sounds (source: anthropic.com/research/developing-computer-use). That's a hard enough problem on its own that routing it to a model or provider chosen specifically for that strength, rather than whichever one happens to be handling the conversation generally, is a defensible architectural choice, not a cost-cutting shortcut.

The reasoning step itself is where the "your specific project" part of TryUncle's pitch actually happens. The model receiving your screenshot and question isn't answering a generic "how do I ripple delete in DaVinci Resolve" question against training data. It's looking at your specific node tree, your specific timeline, your specific panel, at the exact moment you asked, and reasoning about that image plus the accessibility labels laid over it. That's the mechanical difference between asking Uncle and pasting a screenshot into a general-purpose chatbot yourself: Uncle's prompt to the model is assembled automatically, every time, from exactly the two data sources covered above, with no manual copy-paste step for you to get wrong or skip.

**Uncle doesn't run on a single AI model. It routes your screenshot and question across multiple specialized providers, each handling the sub-task it's strongest at.** That's a meaningfully different architecture from a single chatbot answering from a pasted image, and it's the reason Uncle can both reason well about a complex question and point precisely at a small control in the same response.

## How Does Uncle Decide Between a Box, a Circle, a Flying Cursor, or a Demo?

The visual output isn't a single, fixed animation. TryUncle's FAQ describes the pointing mechanism with more specificity than most people realize: "A little cursor flies to the control and a hand-drawn box or circle marks it. For moves that need a drag, like a color wheel, it plays a short looping motion demo" (source: TryUncle's FAQ).

Read that carefully and a pattern shows up. A click-and-done control, a button, a checkbox, a menu item, gets a static marker: a box or circle drawn around it, or a cursor that flies there and stops. A control that needs a drag, a color wheel you pull in a direction, a slider you drag rather than click, gets something different: a short looping demo showing the actual motion, not just the location. That's a meaningful distinction, because "here's where the control is" and "here's the physical motion you need to make with it" are two different pieces of information, and a static box only ever answers the first one.

This maps onto a real interaction-design problem that isn't unique to TryUncle. Pointing at a location on screen is a solved problem, cursors, highlights, and arrows have done it for decades. Communicating a drag gesture, direction, distance, speed, is harder, and it's exactly the kind of instruction that's genuinely difficult to put into words. "Pull the wheel down and slightly left" is a sentence you could type, but reading it and then reproducing the exact motion is a translation step a demo animation skips entirely. This is the same node-order problem covered in TryUncle's own material: knowing where a wrong node is and knowing which direction to drag it are different pieces of information, and the drag-demo mechanism appears to exist specifically to close that second gap.

What decides which output type Uncle uses for a given control isn't published in detail. The reasonable inference, based on what TryUncle's FAQ states, is that it's tied to the control type itself, since the API for a slider or wheel exposed through the Accessibility tree is labeled with a different role than the API for a button or checkbox, giving Uncle's rendering layer a structured signal to choose from without needing to guess purely from the screenshot. This guide can't confirm that specific implementation detail, since TryUncle hasn't published it, but it's consistent with everything covered above about how the accessibility layer supplies role information alongside label and position.

## What's the Difference Between Talk, Check, and Type Under the Hood?

All three shortcuts feed into the same core loop described in the session-flow table above: screenshot, accessibility read, cloud reasoning, spoken and drawn answer. What differs between them is what happens at step 4, how the question itself gets formed.

| Method | Shortcut | How the question is formed |
| --- | --- | --- |
| Talk | Shift+Fn | Your voice is streamed to a speech-to-text provider (AssemblyAI, with OpenAI as a named fallback per TryUncle's privacy policy) and converted into text before it's added to the request |
| Type | Shift+Option | Whatever you type is used directly as the question, with no transcription step needed |
| Check | Shift+Control | No question is typed or spoken at all; Uncle reasons about your current screen and infers what you'd likely want checked |

Talk and Type both require you to formulate a question, in words, before Uncle can act on it. That's a real cognitive step, and it's the same barrier that limits a general chatbot: if you don't know the control is called a "qualifier," you can't easily ask about it by name. Check skips that step entirely. Rather than answering a question you posed, it reasons about the state of your current screen against what a correct version of that state probably looks like, the same mechanism that lets it catch a saturation node placed before a contrast node in a color grade without you ever having noticed something was wrong.

Mechanically, this means Check's cloud request looks different from Talk's or Type's. A Talk or Type request includes a screenshot, accessibility data, and an explicit question string. A Check request includes the screenshot and accessibility data with, at most, an implicit instruction along the lines of "evaluate whether this looks correct," rather than a specific user-authored question. That's a genuinely different prompt shape, and it's a reasonable technical explanation for why Check exists as a distinct interaction mode rather than just being "ask a generic question" folded into Talk or Type.

Talk carries one additional mechanical step neither of the others has: audio has to leave your Mac, get transcribed, and come back as text before the reasoning step can even start. That's an extra network hop, and it's the reason Talk depends on a working microphone permission specifically, on top of the Screen Recording and Accessibility permissions all three methods share.

## How Does Uncle Handle Multiple Monitors Mechanically?

TryUncle's FAQ states plainly that the pointing system "works across multiple monitors, too" (source: TryUncle's FAQ), which matters for the colorist grading on a calibrated reference display while browsing bins on a laptop screen, or the freelancer running a client screen-share on a second monitor.

Mechanically, this is a natural extension of how ScreenCaptureKit works rather than a separate system Uncle had to build from scratch. Apple's own documentation describes the framework's content-selection model as letting a developer "choose the content you want to capture," which can span whichever displays are connected, not just the primary one (source: developer.apple.com/videos/play/wwdc2022/10156/). Screen Recording permission on macOS is typically granted app-wide, not per-display, so once you've approved it for Uncle, there's no separate toggle to flip for a second monitor.

The Accessibility side of the equation follows the same logic: a control's on-screen coordinate is still just a coordinate, regardless of which physical display it happens to sit on, since macOS treats connected displays as one continuous coordinate space rather than as isolated zones. That's what makes cross-monitor pointing mechanically straightforward once both permissions are granted, rather than a feature that needed bespoke multi-display engineering.

What isn't publicly documented is the exact rule Uncle uses to decide which display to point on when your setup spans two or three of them and DaVinci Resolve's windows are split across them. This guide can't confirm whether Uncle targets whichever display currently has system focus, whichever one has DaVinci Resolve's active window, or some other logic. The practical workaround, which also applies to the single-panel mixup covered in TryUncle's own material, is to click into the specific window and panel you're actually asking about before you ask, removing any ambiguity about which screen or panel Uncle should be reasoning about.

One setup this guide genuinely can't speak to is Sidecar, the macOS feature that turns an iPad into a secondary Mac display. TryUncle doesn't mention Sidecar either way in its public FAQ or privacy policy, and iPad-as-display setups sometimes behave differently from a standard external monitor at the operating-system level. Treat that combination as untested rather than assume it works identically.

## What Happens When You're Offline or a Permission Is Missing?

Because the reasoning step happens entirely in the cloud, the mechanism has a hard dependency the earlier steps don't: internet access. TryUncle's FAQ states this directly: "The reasoning runs in the cloud, so Uncle needs to be online to answer" (source: TryUncle's FAQ). There's no local fallback model that kicks in when you're offline. If step 5 in the session-flow table above can't reach the cloud, the loop simply stops there.

Here's what that looks like in practice for each failure mode:

| What's missing | What still works | What breaks |
| --- | --- | --- |
| No internet connection | Nothing. Screenshot and accessibility reads happen locally, but there's nowhere to send them | Uncle can't respond at all, in any mode |
| Screen Recording not granted | Nothing meaningful | Uncle has no picture of your screen, so it has nothing to reason about |
| Accessibility not granted | Spoken or typed answers still work, since Uncle has the screenshot | No drawn box, no cursor movement, since there's no coordinate map to point with |
| Microphone not granted | Check and Type both work fully | Talk (Shift+Fn) has nothing to transcribe |
| A specific AI provider is down | The named fallback likely takes over for that sub-task, per TryUncle's own provider list | This guide can't confirm exact fallback behavior beyond the fallback labels TryUncle names for speech-to-text and visual pointing |

The Screen Recording failure is the most complete one, because it removes the input to the entire pipeline, not just one downstream step. Without a picture, there's no screenshot to reason about, no accessibility overlay to make sense of, nothing to send to the cloud at all. Accessibility failing is a softer degradation: Uncle still has the picture, so it can still form an answer in words, it just loses the ability to translate that answer into a precise coordinate on your screen. That asymmetry is a direct consequence of the architecture covered earlier in this guide: Screen Recording is the input everything else depends on, while Accessibility is an enhancement layered on top of it.

If your studio has unreliable wifi, or you edit somewhere with no signal, that offline dependency is a real, practical constraint worth weighing before you build a workflow around Uncle for anything time-sensitive, not a hypothetical edge case.

## Is Uncle's Mechanism the Same as a Computer-Use AI Agent Like Claude's or ChatGPT's?

Related, but built differently, and the difference is worth understanding precisely rather than glossing over.

Anthropic's own research describes computer-use agents as operating in what it frames as a perception-action loop: the model looks at a screenshot, reasons about what it shows, and decides where to click, working almost entirely from the image itself. Anthropic's account of training Claude for this specifically calls out pixel-level precision as a hard, dedicated problem: the model had to learn to count pixels to figure out exactly how far to move a cursor to land on the correct spot (source: anthropic.com/research/developing-computer-use). That's an impressive capability, and it's also, by Anthropic's own account, a genuinely difficult one to get right from vision alone, closer to how a human infers a click target by eye than to reading it off a blueprint.

Uncle's architecture, based on what TryUncle has published, takes a different path for the pointing half of the job. Rather than asking a model to infer a coordinate purely from pixels, it supplies the coordinate directly, read from the macOS Accessibility tree covered earlier in this guide, alongside the screenshot. That's the difference between an AI that has to visually estimate where a button probably is and an AI that's handed the operating system's own record of exactly where that button is, down to the pixel, without needing to infer anything from the image.

Neither approach is strictly better in the abstract. Vision-only grounding, the kind Anthropic's computer-use research describes, generalizes to any interface, including ones that don't expose clean accessibility data, web pages with custom-rendered elements, games, poorly built apps. Accessibility-tree grounding, the kind Uncle appears to lean on, is faster and more exact when it works, but it depends on the target app actually exposing well-labeled accessibility data for macOS to read in the first place. A well-built, mature application like DaVinci Resolve, built on Apple's standard UI frameworks for most of its interface, is a reasonably strong candidate for this approach. A custom-drawn canvas, the kind of view a node-based compositing tool sometimes uses for its graph editor, is a much harder case for accessibility tooling in general, since custom rendering can bypass the standard control hierarchy the API expects to read (source: research.macpaw.com/publications/how-to-parse-macos-app-ui). This guide can't confirm exactly how Uncle's pointing behaves inside a canvas like Fusion's node graph specifically, since TryUncle hasn't published that level of detail, but it's a real, structural reason the mechanism might behave differently there than it does on a standard toolbar or panel of sliders.

**Uncle's pointing mechanism doesn't have to guess a coordinate from pixels the way a pure vision-based computer-use agent does. It reads the coordinate directly from the operating system's own accessibility data.** That's the specific technical difference between "an AI that estimates where a button probably is" and "an AI that's handed the exact answer," and it's the reason Uncle can draw a box with pixel-level precision rather than an approximate highlight.

## How Fast Is the Whole Loop, Question to Pointer?

This is the honest answer: TryUncle hasn't published a measured end-to-end response time, and this guide won't invent one just to fill a table. What can be said, based on the architecture covered above, is which parts of the loop are fast by nature and which part is where any real delay would live.

The local steps, capturing the screenshot and reading the accessibility tree, are the fast part. A screenshot capture through a modern macOS framework is close to instantaneous, and the accessibility-tree read that one developer analysis clocked at roughly 50 milliseconds (source: fazm.ai/blog/macos-ai-agent), even if you treat that specific figure skeptically as an unaudited estimate, describes an operation that's fundamentally lightweight compared to an image-analysis pass, since it's returning structured text data rather than processing pixels. Drawing the box, circle, or cursor animation afterward is also a local rendering step, and rendering an overlay is not, on its own, a slow operation.

The part of the loop genuinely capable of taking real time is step 5 and 6, the network round trip to multiple cloud AI providers and the reasoning those providers do once the data arrives. Multimodal AI reasoning over an image and a question, especially when it's routed across more than one provider for different sub-tasks as covered above, is not an instant operation for any AI product on the market today, TryUncle included. Add a spoken reply, which requires a separate text-to-speech generation step through ElevenLabs before you hear anything, and there are at least three network-dependent stages stacked before you get an answer: reasoning, potentially a fallback provider for visual pointing, and speech synthesis.

None of that is a criticism specific to TryUncle. It's the shape of every cloud-AI product that reasons over an image rather than matching a fixed database of answers. If waiting even a few seconds for a spoken reply feels slow mid-edit, Type (Shift+Option) at least removes the text-to-speech step from the chain, since you're reading the answer rather than waiting for it to be spoken.

## What Data Actually Leaves Your Mac During This Process?

Walking the mechanism start to finish means being specific about exactly what crosses the wire, not just gesturing at "some data." Per TryUncle's privacy policy, a single question sends out (source: TryUncle's privacy policy):

- **A screenshot** of the active window or connected displays, captured at the moment you ask, not before.
- **Accessibility data**: the labels, roles, and positions of the controls visible in that screenshot.
- **Your question**, as transcribed text if you used Talk, or as typed text if you used Type. Check sends no separate question text.
- **Setup details**: the names and counts of plugins, LUTs, fonts, and which Resolve version you're running, so answers match your actual environment.
- **Your account email**, captured once through Google sign-in, to identify your subscription.

What explicitly does not leave your Mac, per the same policy: your actual project files, your actual media, and your raw footage. TryUncle states this directly: "Your media never leaves your Mac" (source: TryUncle's site). The screenshot shows what your footage looks like on screen at that instant, which is a meaningfully smaller and more contained thing than the underlying media file itself, the same way a photo of a document isn't the same as handing over the original file.

**Every piece of data Uncle sends to the cloud is generated fresh at the moment you ask a question. Nothing is captured or transmitted in the background.** That's a specific, checkable claim, not a vague privacy promise, and it follows directly from the on-demand screenshot mechanism covered earlier in this guide.

If you're weighing this against an NDA or a studio security policy, the mechanism itself is the thing to check against that policy's actual language, not TryUncle's marketing summary of it. A policy that prohibits "third-party screen-sharing tools" might or might not draw a distinction between continuous sharing and an on-demand, single-frame capture, and that's a determination worth making with whoever owns the NDA, not from a blog post.

## What Happens to the Screenshot After Uncle Answers?

The mechanism doesn't end when the box gets drawn on your screen. The screenshot and the data sent alongside it have their own lifecycle after that point.

Per TryUncle's privacy policy, screenshots are automatically deleted after 30 days (source: TryUncle's privacy policy). Account information persists only as long as your account exists, and setup snapshots, the plugin and font inventory covered above, are removed the moment you delete your account. On the usage side, the company states directly: "We do not sell your personal information, and we do not use your screenshots, voice, or messages to train our own AI models" (source: TryUncle's privacy policy).

That last line matters specifically because of the multi-provider architecture covered earlier in this guide. Your screenshot briefly passes through Google, Anthropic, and OpenAI's infrastructure on its way to becoming an answer, and each of those companies has its own separate data policies for API traffic that route through their systems. TryUncle's commitment covers what TryUncle itself does with the data once it's collected and after it's returned from those providers; it isn't a substitute for reading each provider's own API-level data handling terms if that level of detail matters for your specific compliance situation. This guide can't independently verify each provider's individual retention practice for API calls made through TryUncle specifically, since that data isn't published by TryUncle at that granularity.

If you want your data removed, corrected, or copied outside the standard 30-day window, TryUncle's privacy policy names a contact route for that request rather than requiring you to dig through account settings for a deletion flow.

## Why Build It This Way Instead of a Simpler Architecture?

A fair question, since everything covered above is more moving parts than "one AI model looks at a screenshot and answers." A single-model, screenshot-only approach, closer to Anthropic's computer-use research covered earlier, would be simpler to build and would still produce a working product.

The trade-off is precision at the point that matters most: the moment the box lands on your screen. A vision-only system estimating a click coordinate from pixels alone is doing genuine inference, and inference carries error. Anthropic's own account of building that capability describes pixel-counting accuracy as something that required deliberate, dedicated training effort, not something that came for free from general image understanding (source: anthropic.com/research/developing-computer-use). Layering the Accessibility tree on top of the screenshot, as Uncle's architecture appears to do, removes that inference step for the pointing half of the job entirely, for any control that exposes proper accessibility data. Instead of estimating, Uncle reads.

The multi-provider routing follows a similar logic, applied to the reasoning half of the job rather than the pointing half. Rather than accepting whichever single model's weaknesses show up on a given question, whether it's slightly worse at visual precision, slightly slower at speech synthesis, or occasionally unavailable, the architecture spreads the job across providers chosen for specific strengths, with named fallbacks for at least two of the sub-tasks. That's a more expensive and more complex system to operate than a single-model integration, and it's also a more resilient one, at the cost of the exact tradeoff covered earlier in this guide: your data touching more outside companies on the way to an answer.

None of this is unique reasoning limited to TryUncle. It's the same tradeoff every serious AI product built on top of foundation models eventually faces: simplicity and a single vendor relationship, against precision and reliability assembled from several specialized pieces. TryUncle's own published architecture, as far as it's documented, has chosen the second path.

## What Are the Mechanism's Actual Limits?

Every piece of architecture covered in this guide has an edge where it stops working as cleanly as it does in the ideal case, a colorist adjusting a well-labeled slider on the Color page. Here's where those edges are, stated plainly rather than buried in a features list.

- **Custom-rendered canvases are the weak point for the Accessibility half of the mechanism.** Standard menus, buttons, and sliders are exposed cleanly through the macOS Accessibility API because that's exactly what the API was built to describe. Canvas-style views, which node-based graph editors like Fusion's often are, don't always map cleanly onto the same standard control hierarchy, a known challenge in accessibility tooling generally (source: research.macpaw.com/publications/how-to-parse-macos-app-ui). This guide can't confirm how much of a real-world difference this makes for Uncle specifically inside Fusion, since TryUncle hasn't published that detail, but it's a structural reason to expect the pointing mechanism might be less exact there than it is on a standard toolbar.
- **Fairlight's coverage is a documentation gap, not a confirmed capability gap.** TryUncle's own site names delivery specs, plus Edit, Color, and Fusion, as covered surface. It doesn't name Fairlight, Resolve's dedicated audio page, one way or the other in the public material this guide could verify. The mechanism itself, screenshot plus accessibility read plus cloud reasoning, doesn't inherently exclude Fairlight's panels; there's simply no public confirmation of how thoroughly it's been tested there.
- **The offline dependency is absolute, not partial.** Because reasoning happens entirely in the cloud, per TryUncle's own FAQ, there's no degraded, lower-quality mode that works without internet. It's fully functional or fully unavailable, with nothing in between.
- **The mechanism depends on DaVinci Resolve continuing to expose standard accessibility data as it's updated.** This isn't a criticism of TryUncle specifically, it's a general risk for any tool built on top of another company's UI. If a future Resolve update changes how a panel renders in a way that breaks how it exposes accessibility data, Uncle's pointing precision for that panel could degrade until TryUncle adapts to the change, the same way any accessibility-dependent tool has to track the apps it supports.
- **A vision-only fallback for unlabeled controls isn't publicly documented.** When Accessibility data for a specific element is missing or incomplete, this guide can't confirm whether Uncle falls back to a pure screenshot-based estimate for that one element, the way a computer-use agent would, or whether it simply can't point precisely at that control at all. Both are plausible engineering choices and TryUncle hasn't stated which one it made.

Naming these limits plainly matters more than a clean pitch, and it's consistent with how TryUncle's own FAQ handles the questions it can answer directly: clearly, with specifics, rather than a vague reassurance.

## Who Built the Mechanism This Guide Just Walked Through?

TryUncle is built by Marius Manolachi, who runs the DaVinci Resolve 21 Learning Group on Facebook, a community that has grown to roughly 99,000 members, through which he has personally taught DaVinci Resolve to somewhere around 100,000 people (source: facebook.com/groups/5399253026772333). That background is relevant to a post about mechanism specifically for one reason: the architecture covered in this guide, screenshot plus accessibility read plus cloud reasoning, is a direct engineering answer to a very specific, repeatedly observed problem, someone stuck on a control they can't name, in a project the instructor has never seen, needing an answer that matches their exact screen rather than a generic one.

Blackmagic Design's own free training material, hundreds of pages of structured guides covering editing, color, and effects, already exists for the reader who wants a full curriculum from zero (source: blackmagicdesign.com/products/davinciresolve/training). Resolve Studio itself is a one-time $295 purchase with no subscription attached (source: blackmagicdesign.com/products/davinciresolve/studio). Uncle isn't trying to replace either of those. The mechanism it's built around solves a narrower, different problem: the exact moment mid-edit when you know something's wrong but can't name it, which no static document, however comprehensive, can watch your specific screen and answer for you.

## Does the Mechanism Actually Work in Practice?

Testimonials aren't a substitute for testing something yourself, and TryUncle publishes these on its own site rather than through an independent reviewer, so read the following the way you'd read any vendor-selected quote: as an example of a best-case outcome under the mechanism described above, not a guarantee. With that framing stated plainly, here's one, quoted verbatim:

> "Blown-out sky in a wedding edit. I asked, it circled the fix, done before my coffee went cold."
> - Priya S., wedding filmmaker (source: TryUncle's site)

Read against the mechanism this guide just walked through, that quote lines up with the architecture rather than contradicting it. A blown-out sky is exactly the kind of visual problem a screenshot captures clearly, and "it circled the fix" describes precisely the static-marker output covered in the pointing section above, a control identified through the accessibility layer and marked with a drawn shape rather than described in a paragraph of text she'd have to translate into a click herself.

The right test isn't a testimonial, yours or anyone else's. It's opening your own project, getting stuck on something specific, and watching whether the mechanism described in this guide, screenshot, accessibility read, cloud reasoning, drawn pointer, actually closes the gap between "I don't know how" and "I did it" faster than searching for it yourself would. TryUncle's 14-day refund guarantee exists specifically so that test costs you nothing but the time it takes to run it, at [TryUncle](https://tryuncle.com).

For the full picture beyond just the mechanism, what TryUncle costs, who it's for, and how it stacks up against a course subscription, see [what TryUncle actually is](https://tryuncle.com/learn/davinci-resolve/what-is-tryuncle). And if you're comparing it against other AI options for learning Resolve, ChatGPT, Claude, Blackmagic's own free training, see [our full comparison of AI tools for learning DaVinci Resolve](https://tryuncle.com/learn/davinci-resolve/ai-tools-to-learn-davinci-resolve). If the deeper question behind all of this is why watching someone else work doesn't build your own skill the way doing does, that's covered in full in [why watching tutorials doesn't work](https://tryuncle.com/learn/ai-at-work/why-tutorials-dont-work), and if you're weighing TryUncle against a structured curriculum instead, [our guide to the best way to learn DaVinci Resolve](https://tryuncle.com/learn/davinci-resolve/best-way-to-learn-davinci-resolve) lays out that broader roadmap.

## The Mechanism, In One Place

Strip away the marketing language and TryUncle's Uncle is a five-part pipeline: a local screenshot, a local accessibility read, a cloud reasoning step spread across several specialized AI providers, a spoken or written answer, and a locally-rendered pointer drawn back onto your screen. Every constraint worth knowing before you rely on it, the need for two separate permissions, the internet dependency, the multi-provider data flow, the likely soft spot around custom-drawn canvases, follows directly from that architecture rather than being an arbitrary limitation.

That's the honest version of "how does TryUncle work," built from what the company has actually published and from the public documentation of the macOS frameworks the product has to be built on, not from a single marketing sentence. If the mechanism holds up the way it's described here, the fastest way to confirm it is still the same one this guide keeps returning to: open your own project, get stuck on purpose, and watch where the box lands.



## FAQ

### What actually happens between the moment I ask Uncle a question and when it answers?

Uncle takes a screenshot of your screen, reads the labels and positions of every visible control through macOS Accessibility, sends both plus your question to cloud AI providers, gets back a spoken answer and a target control, then speaks the answer while drawing a box or circle around that control or flying the cursor to it on your actual screen.

### Does Uncle see my screen constantly, or only when I ask it something?

Only when you ask. TryUncle's own FAQ states there is 'no background recording, no always-on listening, and no continuous screen monitoring,' and a screenshot is captured at the moment you use Talk, Check, or Type, not before and not continuously in between.

### Why does Uncle need both Screen Recording and Accessibility permissions instead of just one?

Screen Recording gives Uncle a picture of your screen, which is enough to understand what you're looking at and answer in words. Accessibility gives it the coordinates and labels of every control in that picture, which is the only way it can draw a box around the right slider or fly a cursor to it instead of just describing where it is.

### What AI models does Uncle actually use to answer my question?

According to TryUncle's privacy policy, it routes your screenshot and question through Google's Gemini for core reasoning, Anthropic and OpenAI for visual pointing precision, AssemblyAI for speech transcription, and ElevenLabs for the spoken reply, rather than relying on a single model for the entire loop.

### How does Uncle decide whether to draw a box, a circle, fly the cursor, or play a demo?

TryUncle's FAQ describes a cursor flying to the control with a hand-drawn box or circle marking it for a single click or selection, and a short looping motion demo for moves that need a drag, like turning a color wheel, matching the visual to what your hand actually needs to do next.

### Is Uncle's mechanism the same thing as Anthropic's or OpenAI's computer-use AI agents?

Related but not identical. Anthropic's computer-use research describes a model that works from screenshots alone and learns to count pixels to find a click target. Uncle adds a second data source, the macOS Accessibility tree, which hands over exact control coordinates directly instead of asking a model to infer them purely from pixels.

### What happens to the screenshot after Uncle answers my question?

Per TryUncle's privacy policy, screenshots are automatically deleted after 30 days, and the company states it does not sell personal information or use screenshots, voice, or messages to train its own AI models.

### Does this mechanism work the same way in Fusion's node graph as it does on a normal toolbar?

This guide can't confirm that with certainty. Standard menus, sliders, and buttons are well-covered by the macOS Accessibility API by design, but custom-drawn canvases, which node-based compositing views often are, are a known soft spot for accessibility tooling in general, and TryUncle hasn't published implementation detail on how its pointing degrades, if at all, inside Fusion's node canvas specifically.

## Sources

- [TryUncle](https://tryuncle.com)
- [TryUncle FAQ](https://tryuncle.com/faq)
- [TryUncle Privacy Policy](https://tryuncle.com/privacy)
- [ScreenCaptureKit (Apple Developer Documentation)](https://developer.apple.com/documentation/screencapturekit/)
- [Meet ScreenCaptureKit - WWDC22 (Apple Developer)](https://developer.apple.com/videos/play/wwdc2022/10156/)
- [AXUIElement (Apple Developer Documentation)](https://developer.apple.com/documentation/applicationservices/axuielement)
- [Parsing macOS application UI: Techniques and tools (MacPaw Research)](https://research.macpaw.com/publications/how-to-parse-macos-app-ui)
- [macOS AI Agent: How Desktop Agents Work on Mac in 2026 (Fazm)](https://fazm.ai/blog/macos-ai-agent)
- [Developing a computer use model (Anthropic)](https://www.anthropic.com/research/developing-computer-use)
- [DaVinci Resolve Training (Blackmagic Design)](https://www.blackmagicdesign.com/products/davinciresolve/training)
- [DaVinci Resolve - Studio (Blackmagic Design)](https://www.blackmagicdesign.com/products/davinciresolve/studio)
- [DaVinci Resolve 21 (Learning Group) - Facebook](https://www.facebook.com/groups/5399253026772333/)