Yes, ToS might be set as close to origin as possible, including on the source, itself, but there's more to it than that.
For starters, a ToS marking, like your mention of DSCP AF21, is just a "shortcut" for analysis of a packet's QoS needs. It may, or may not, properly represent the service needs of the marked packet. "Incorrect" markings might be accidentally wrong, intentionally wrong, or just not aligned with your usage of ToS markings. So, when entering your "trust" boundary (the boundary where packets pass into your control/management of ToS), the ToS marking often should be checked to insure that it truly represents the proper classification for that traffic. Lastly, ToS markings are subject to rewrite. This might be done for various reasons, on devices within your management. (It also might be done on network devices under someone else's management.) Again, remember ToS is a "shortcut" to allow a network device to easily/quickly classify a packet's QoS needs, but such classification can be done without using ToS.
Most network devices, by default, don't provide any QoS treatment until configured to do so. So, yes, you often need to go to all your devices and insure they have a QoS policy that meets your service needs. Two things to assist you in dealing with the "burden" of doing this, many Cisco devices have an "auto-QoS" feature, where one command will configure a more, or less, complex QoS policy that Cisco believes will deal with most QoS needs. (Of course, Cisco's auto-QoS policy might not be suitable for your QoS needs, and even if it is, you need to understand their policy to use it optimally.) Second, QoS is only really needed at bottlenecks/choke-points that have congestion that's adverse to service needs. LAN to WAN (i.e. egress WAN ports) is usually a "poster child" for such.
In your case, without knowing more about your devices, topology and service needs, I cannot make detailed suggestions. However, if you're using routers, not switches, for your WAN connections, and the WAN port's physical bandwidth does not have some WAN provider lessor bandwidth limit, the following QoS policy often works very well for multiple needs.
service-policy GeneralQoS
class class-default
fair-queue
interface !wan
service-policy output GeneralQoS
You mention the possibility of marking traffic as "scavenger". That's fine, but then you need a policy that does "something" about scavenger traffic. (I don't recall Cisco's auto-QoS policy supporting scavenger usage.)
The following policy, might support scavenger traffic, and a bit more too.
service-policy GenericQoS
class real-time !might be used for VoIP bearer traffic, etc.
priority percent 35 !Cisco recommends only up to 1/3, but I found up to 40% works pretty well too
class foreground !used for highly important, light bandwidth flows, like VoIP control traffic
bandwidth remaining percent 81
fair-queue !possibly not needed, but good insurance if one flows wants "too much" bandwidth
class background !can be used for scavenger or other bulk data flows
bandwidth remaining percent 1
fair-queue !also possibly not needed, but avoids some other issues with multiple heavy bandwidth usage flows
class class-default !your "BE" class, which should really contain all but traffic you direct to the other classes
fair-queue !highly recommended for this class
bandwidth remaining percent 9
The above requires class-maps to match traffic to other than the class-default, e.g.
class-map match-any real-time
match ip dscp ef
class-map match-any background
match protocol ftp
Feel free to ask additional questions.
