AI Should Be a Filter, Not a Firehose

I noticed this while building Unix shell tools for a data pipeline. The commands I reached for were there to narrow the space: find the pattern, extract the field, remove duplicates, count, sort, and show the few lines worth inspecting.

That is a useful standard for AI as well. People already receive more messages, alerts, documents, and generated summaries than they can reasonably process. A system that reads across those sources should leave the person with less avoidable reading and a better basis for a decision.

Producing another report is easy. Deciding what can safely be left out takes more care.

A pipeline is a set of choices

Take a simple shell pipeline that searches an event log, extracts selected fields, counts repeated values, and ranks the result:

cat events.log \
  | grep "error" \
  | awk '{print $1, $4}' \
  | sort \
  | uniq -c \
  | sort -nr \
  | head

Every stage removes something. That is how the pipeline becomes useful, and how it can become misleading. A filter can omit the one exception that matters. A count can combine events that look similar but have different consequences. A ranked list can make an artifact of measurement look like a priority.

The important question is what must remain visible for the next person to judge the result. A shorter answer is not automatically a more useful one.

Decide what deserves attention

Analytics already does much of this work. Aggregation exposes patterns. Filtering defines the relevant records. A time window determines what counts as current. Ranking turns an undifferentiated collection into a proposed order of attention.

AI can extend those operations into material that is harder to query directly: a set of emails, free-form field notes, a call transcript, or several documents using different names for the same thing. It can group related evidence and prepare a smaller review surface.

But the review surface needs a purpose. A summary prepared for a maintenance supervisor deciding tomorrow's priorities should preserve different details from one prepared for an engineer investigating a particular failure. Without a decision in view, “summarize everything” often just creates another document that somebody has to read.

Start by asking the operator what could change the decision. Then ask which evidence would make that change credible. That gives the filter a job more precise than making the material shorter.

Keep the things judgment depends on

Useful reduction should preserve the signal that could change the decision, the context that explains it, and the trail back to its source. It also needs to retain unresolved uncertainty and show which next action the evidence can support.

A maintenance example makes the distinction concrete. Suppose an illustrative report flags a repeated fault. The count may be relevant, but the supervisor may also need to know that all reports came from one sensor, that its calibration is old, and that an inspection is already scheduled. Removing those facts can make the alert more concise while making the decision worse.

The system should let the reviewer open the cited evidence at the point of the claim. A link to a folder full of files leaves much of the reconciliation work with the person. A record, passage, or observation tied to the statement is more useful.

Listen when the operator puts something back

Experienced people reveal the limits of a filter when they hesitate, override a recommendation, or open another source to double-check it. Those behaviors deserve investigation, not automatic interpretation.

A hesitation may signal missing context. An override may expose a hidden constraint. A double-check may reveal weak provenance. It may also mean the interface is unfamiliar or the recommendation was misunderstood. Ask the operator before deciding what the behavior means.

If a reviewer repeatedly restores the same detail, find out why it was removed. The answer may belong in the filter, in a source-quality check, or in a case-specific note. Preserve the reason and its scope so that one correction does not quietly become a rule for every situation.

Measure the burden that remains

The useful test happens after the system produces its answer. How much material did the person still have to inspect? Could they check the source without reconstructing the whole task? Did they discover that an important exception had disappeared?

Compare the proposed review surface with the existing process. Include the effort of verifying it. A report that takes less time to prepare but longer to check may offer little benefit, particularly if it makes omissions difficult to notice.

Also keep examples where the filter was wrong. Test whether a repair preserves the cases it already handled well. The system should improve from the review, rather than merely learn which style of summary receives the fewest objections.

I want AI to do more of this sorting before information reaches the person. The test I would use is whether the operator has fewer things to reconcile, enough evidence to question what remains, and a clearer next decision.