Yes, we're deeply inspired by all the work in distributed computing which came before us - Hadoop, Spark, Kubernetes, etc... there are so many. We're just trying to focus on the case that feels unmet by these centralized solutions (not a replacement, a compliment).
You can read more about our architecture here[1], but to get to your answer, we have two forms of consistency. First, when creating your network, you create a series of "requestor" nodes - as many as you'd like, in as many places as you feel you need to have redundancy. Unlike something like Kubernetes, where the state is managed by etcd (or other store), we manage that internally. That's not saying etcd is bad! But by managing this ourselves, it allows us to be smart about distributing job state between many requestor nodes around the network - spinning up new ones, and having them join the consistency group is just one command.
Further, when a node takes on a job, the state (such as it is) gets transferred to that node as the source of truth. This is a lot like Kubernetes but with much better support for "coast mode" - if that node is disconnected, but still in the timeout window, the system is perfectly fine with it, and when it reconnects, everything resolves. (In the centralized world, things are blown away and rescheduled quickly)
We looked at things like CRDTs and are currently doing a lot of thinking about more resilient ways to handle partitions and consistency - if you'd like to jump over to our slack[2]/repo[3], we'd love to talk more!
[1] https://docs.bacalhau.org/getting-started/architecture