The short answer is this: You have two problems. First, negation in a where clause is inefficient because it has to retrieve all potential matches prior to negating them. Second, path match in a where clause is inefficient because it must recheck the path for every row of the preceding match clause.
The solution is think in terms of deforming and reforming your graph. Rather than treating it gently, as we must with relational databases, consider what graph patterns would make your query efficient. Then create that pattern, and query against it instead.
You graph must be structured for efficient queries to be useful, that's why good data design models are much more important to Graph DBs than anywhere else.
The hard and fast rule is this:
Relationships between nodes should be many in, out few Or more simply, arrows from children to parents, Match in the direction of your arrows.
That said, try a quick fix for now:
(watch the semicolons ;, if you're using the Browser, you'll need to run each command separately.)
MATCH (ap:AgamPolicy)
SET ap.hasReport = 0; # give them all a default 0
MATCH (ap:AgamPolicy)-[:RELATED_TO]->(:PolicyAccount)-[:LAST{fetch:true}]->(:PolicyReport)
SET ap.hasReport = 1; # those with a report, set to 1
MATCH (ap:AgamPolicy)
WHERE ap.hasReport = 0
RETURN count(ap); # match those still without a report
MATCH (ap:AgamPolicy)
REMOVE ap.hasReport; # revert changes, removing that property