You need to understand how source engine decides what things to render in order to understand these entities. Since you didn't say much, I'll start from the top.
Basically, the map is divided up into sections known as "partitions" or "leaves" (they're basically the same idea, but a leaf can be made up of multiple partitions; that's what viscluster is for).
The areas that connect "partitions" or "leaves" are called portals, and the compiler makes something called a "stab tree" through various portals to best figure out what leaf can see eachother.
The idea is that a viewpoint inside of a given camera will definitely not be able to see objects that are strictly inside of certain other ones. For example, someone who is on the opposite side of a wall to you. So, what they did, is, for a certain leaf, a camera inside of it will only render objects and map elements that overlap the other leafs in its "potentially visible set" (PVS) of leafs. For a given general area, the compiler will decide whether every single other general area in the level is visible, or not, from said first general area.
This is a (simplified) example of how part of a map may look to the visibility system. The red boxes are leaves; they're the "general areas" that the compiler and game look at to decide what is visible. Note that a leaf *needs* to be completely convex, for mathematical reasons. Also, the most common (and slightly cheapest to compile) kind of leaf is an orthogonal rectangular one. So you're going to have things like this.
The green numbers all represent objects that might exist in the world and need to be drawn, like health kits, enemies, guns, players, props, whatever. If you can draw a line from any part of the leaf that a single object is in, to any other leaf, without crossing through the void, then an object in that other leaf's contents will be visible to that single object.
--------------------
Hints
The problem with this is, sometimes you get leafs that aren't aggressive enough; they extend out into areas in ways that are suboptimal. In the example image up there, the leaf that the 4 is in extends over to the walkway that the 3 is on. This is bad because it makes it so that the 4's visleaf can draw a line to the 5's visleaf. You can use a hintbrush to force that 4's visleaf to be cut off at the end of the stairs, so that the 4's stairs and the 5's stairs can't "see" eachother.
You might also notice that the 3 can technically "see" the 1. You can avoid this by cutting off the 1's visleaf something like this:
https://developer.valvesoftware.com/wiki/File:Hint_example4.jpg
...Finally, the 2 can see every leaf here, which is good enough.
----------------------------
Areaportals
Let's say you have an extremely detailed area where hint brushes wouldn't do justice without using like eighty. You want that area to be mostly invisible to areas outside of it. So what you do is, you make all of its entrances have areaportals in them, so that only the parts visible through the entrances (when you're outside of it of course) need to render.
https://developer.valvesoftware.com/wiki/Areaportal#Performance_impact
Areaportals also make VRAD run a little faster because of the little extra information they add to the map's file with grouping partitions into areaportal areas. That's something I can't really explain in depth.
