ABI (Application binary interface) defines things like caller and callee saved registers, stack use, register use, end-of-routine stack pop etc.
Is ABI only an agreement between compilers and other software to make sure they don't overwrite each other, or is it also governed by the hardware itself? i.e if we all agree on using caller saved registers as callee saved registers things will continue to function normally as the hardware doesn't really care?
It can be both. An ABI is a convention, and there might exist several such conventions for a given hardware architecture (see https://en.m.wikipedia.org/wiki/X86_calling_conventions) but in general they are at least partly directed by the architecture features.
For example, a processor architecture may define a standard return address register which is set by call instructions but at the same time allow other registers to be used for indirect calls, so a compiler could potentially define a different ABI but would go "against the grain" in doing so.
ABIs are a convention. There can be multiple conventions in use on a single platform - a classic example is early Windows using "Pascal" calling convention despite many of the parts being written in C.
is the CPU hard coded somehow to see it as a "callee saved" register
The only thing that matters here is "what does the CPU actually do when you call/return". This is nearly always that it saves/restores the program counter and nothing else.
(Some architectures really do "caller save" in hardware, but this isn't very widespread)
If you overwrite a callee-saved register, nothing happens and the CPU neither knows nor cares .. until you return. At which point it depends on whether the calling function actually uses the value you've overwritten. You might get away with it, you might crash the program, you might just corrupt the results.
For example how do you arrange the arguments for a function on a stack?
Both have upsides, and both have downsides. But neither is enforced by the hardware.
On the other hand datatype alignment is influenced by the hardware. The hardware is usually optimised to store specific types of operand at specific byte alignment offsets. Some platforms do support loading unaligned data, but there is usually an associated performance penalty. As such these alignments are somewhat/fully specified by the hardware.
Oddly enough some of the ABI isn't specified by hardware, but by platform. After all, to do just about anything on a computer these days, you must interact with the Operating System, and that OS has specific expectations about how it is to be interacted with.
