It’s very common to write one flow for one specific object. This applies whether it’s a screen flow or an autolaunched flow (This obviously doesn’t apply for record-triggered flows).
For either scenario, you typically pass at least one input text variable (e.g. recordId), and then do a get operation to retrieve the entire record.
However, it’s not very common to make agnostic flows. This allows one flow to be called from multiple objects.
For example, imagine a screen flow that looks up a custom mapping object. The mapping uses the object as an input, to know which object the flow was called from.
One of the first steps in the flow needs to determine which object called it. But once you know the object’s prefix, this step becomes easy enough.
You can use a decision element to examine the first 3 characters of the record. If it’s “001” then the source is an account. If it’s “003”, then it’s from a contact.
The takeaway
Making flows agnostic is a great way to keep business logic centralized. And examining the object’s prefix allows your to make an agnostic flow