Franz Enzenhofer shipped a small macOS tool called big-arrow. It does one thing: it lets an AI agent paint a big arrow and a sign on your screen, pointing at the exact field, button, or window that needs a human. No chat window, no log file to scan. Just an arrow on the thing you have to look at. It went up on Hacker News, picked up a wave of questions about focus stealing and trust, and the author answered them in the README within hours.

That tiny project exposes something most automation programs get wrong. Your agent is probably capable enough already. What breaks is the handoff, the moment work passes back to a person. This post covers why visible AI agents close that gap, and what it changes on your floor.

Your AI Agent Finished the Work. Nobody Noticed.

Most agentic workflows fail at the last inch. The agent pulls the batch records, cross-checks the deviation log, drafts the CAPA summary, and then writes a line in a terminal nobody has open. Four hours later someone asks why the approval never came through. The model did everything right. The signal landed where no human was looking.

Logs, chat panes, and Slack threads are all pull interfaces. They assume an operator who is monitoring. Your quality manager is on the floor, in a supplier call, or clearing an audit finding. They are not watching your agent’s output stream.

Which is why a CLI that paints an arrow directly on the screen, pointing at the exact field that needs a signature, is a sharper idea than it looks. It pushes. Visible AI agents interrupt on purpose.

What big-arrow-on-the-screen Actually Does

The tool is a command line program called bigarrow, written in Swift for macOS and released under an open licence. It draws an arrow, a box, a ring or a text sign on top of whatever is already on screen. The overlay is click-through, so it sits above the window without taking focus or blocking the user from working underneath it.

Lifetimes are explicit. You can set --duration, run start and stop manually, add a --close-button, dismiss on --until-click, or use --follow so the arrow tracks a window as it moves. A recent commit added copy buttons, so a value rendered in the sign (a PIN, a batch number, a reference code) can be copied with one click.

Targeting a specific UI element, not just screen coordinates

Most overlay hacks point at pixel positions and break the moment someone resizes a window. bigarrow supports --at and --rect for raw coordinates, but also --mouse, --window and --element, the last one resolved through the macOS Accessibility API.

That matters operationally. The agent says “point at the approval field in this record,” not “point at 1240, 680.” It also accepts Peekaboo JSON, so a screen-reading step can feed the target straight into the arrow.

Packaged as an agent skill, not just a command

The repository ships a skill/big-arrow directory. The agent gets instructions on when to point, what to write on the sign, and how to phrase it. On approvals, the skill tells the sign to state what the click actually does.

That packaging is the real work. A CLI is a capability. A skill is a behaviour rule your agent follows without being asked each time.

The Design Choices That Make It Usable Instead of Annoying

Why click-through and focus-free matters more than visual polish

The overlay runs at window level 1000, above normal application windows, without requesting focus. A Hacker News commenter asked exactly this: how is it in front without focus? The answer landed in the README. That one constraint decides whether the tool gets adopted or uninstalled in a week.

Anything that grabs focus steals a keystroke. A quality manager mid-sentence in a deviation report loses the sentence. Do that three times and the operator kills the process. Interruption tools earn their place by being ignorable until the moment someone chooses to look.

The same logic drives the outline-only rendering. Boxes and rings are drawn as outlines, never filled, so the field underneath stays readable. If your marker covers the data the human needs to judge, you have moved the bottleneck, not removed it. When the agent genuinely needs the target app in front, that is a separate explicit command (front or --raise), not a side effect.

Stating the consequence before the click

On approval prompts, the sign says what the click actually does. Not “confirm”, not “review required”. The specific consequence of pressing the button. That is a deliberate design rule written into the skill definition.

Most approval UX fails here. The human sees a prompt, lacks context on what the agent decided and why, and either rubber-stamps it or escalates to someone who also lacks context. Both outcomes destroy the value of having a human in the loop at all.

Write your handoff prompts the same way. State the action, the affected record, and what happens next if approved. Three lines, no ambiguity.

Where This Pattern Fits in Quality and Operations Work

The repo leads its use cases with guiding and helping someone. That is the same job a work instruction does, except generated on demand, for one person, pointing at one field. An agent that drafted a deviation report can park an arrow on the single line a quality manager has to verify. An agent that ran a tolerance check can point at the exact ERP row that failed, not a row number in a log.

Approval moments where a human signature is legally required

Regulated environments will never let an agent sign. GMP batch release, supplier deviation sign-off, calibration records under ISO 9001, all of it ends with a named human taking responsibility. That constraint is not going away, so stop designing around it and design for it.

The skill handles this directly: on approvals, the sign says what the click does. Not “action required.” The specific consequence of pressing the button. That is the difference between an approval someone reads and an approval someone clicks through at 4:50 on a Friday.

Guiding operators through software they use twice a month

Every plant has a system people touch rarely. The non-conformance module. The supplier portal. The MES screen for a product line that runs one week a quarter. Operators relearn it every time, and that relearning is where the data quality goes bad.

A pointer that walks someone through the sequence beats a PDF nobody opens. The arrow is on the actual screen, in the actual state, with the actual field highlighted. For onboarding, it removes the shadowing shift. For rare workflows, it removes the Teams message to the one person who remembers how it works.

Where It Wins and Where It Breaks Down

Be clear about the ceiling. This is a macOS binary, written in Swift, running locally on one machine for one user. There is no server, no fleet management, no way to push an arrow to forty stations on a line. If your use case involves an HMI panel, a Windows SCADA terminal, or a shared workstation on the shop floor, this tool does nothing for you.

The second cost is tokens. Packaging the overlay as an agent skill means the instructions sit in context on every run, and a Hacker News commenter raised exactly that objection. The author answered it in the README rather than dodging it, which tells you something about how the thing is maintained. Still, you are paying context budget for a capability your agent uses maybe twice per task.

The win sits in the knowledge-work layer. Process engineers, production planners, quality managers, anyone working through an ERP screen or a document queue on a laptop. That is where an agent finishes a piece of work and needs one specific human to look at one specific field. Pointing beats paging.

In a validated environment, treat the overlay as a prompt, never as a record. An arrow on screen is not an audit trail, not an electronic signature, and not a controlled work instruction. It gets the right person to the right field faster. The signature, the timestamp, and the reason code still have to land in your validated system, and your CSV documentation still has to describe how the agent reached that point. Visibility speeds up the handoff. It does not replace the controls around it.

Designing the Handoff Layer Before You Scale Agents

One agent is a demo. Twelve agents running across quality, planning, and supplier management is an operating model, and the thing that buckles first is not the model. It is the queue of decisions waiting on a person who does not know they are waiting.

Treat the handoff as a deliverable with its own spec, same as you would an interface between two machines. Three things belong in that spec: which decisions require a human, how the agent raises its hand, and how long it holds before escalating or rolling back. Write it before you add agent number two. Retrofitting handoff rules onto a dozen live workflows costs more than building them in.

A three-question audit for your existing agent workflows

Sit with whatever you have running today and answer these, per workflow:

• Where does it stop: list every point where the agent needs a human decision, approval, or correction.
• How does the human find out: a log line, a Slack message, an email, or something that reaches them where they are actually working.
• What is the wait: measure the gap between the agent pausing and the human acting. Not the average, the worst week.

Count how many of those stop points depend on someone checking a channel they are not watching. That number is your baseline. If an agent saves two hours of analysis but the output sits idle for six, you have moved the delay, not removed it. The big-arrow README leads its use cases with guiding and helping someone, which is a better description of the missing layer than most enterprise automation roadmaps manage.

Source: github.com