But even "coordination work" is fairly abstract.
A slightly less abstract summary is "assigning scare resources".
Imagine that you are a world dictator, and to keep things simple, you want to build an agrarian utopia. However, instead of Pol Pot, you are actually not an evil guy, and you genuinely want people to live happily and have enough food.
Okay, so you have a certain budget each year. Or, to remove the complications of using money, you have a certain amount of resources (including man-days) that you can spend during that year. How much will you (make your subjects) spend, assuming that they are 100% obedient, so no need to actually spend most money on your personal security...
...it gets complicated quickly. And the more you think about, the more complicated it gets. For example, you still need some form of education, even if it is "narrowly" focused on agricultural work, iron machine design, construction, etc.
One part of the "economy" is that these things often just happen, by random people finding their personal motivation (often profit) to research them, do them, and maybe suffer a personal loss if their guess was wrong.
IDK if it's historically true, but I've read that the origin of coinage was to make it possible for governments to automate the provisioning of their armies. Instead of directly controlling it all, you mint coins, give them to soldiers, tell the soldiers what they're responsible for, and make a law that every citizen has to pay a certain amount of those coins in taxes each year. Directly or indirectly, everyone has to do something to benefit the soldiers in order to get those coins.
(This is a reasonable comment and an appropriate answer to the question in the OP. I happen to already know this, so it's not so interesting to me, but it might be interesting to other people. I am more interested in, what are the concrete types of tasks, decisions, constraints, environments, interactions, etc. that happen in the economy. Which can involve coordination tasks, but not just coordination tasks. That said, I don't mind this big picture/theoretical comment. Just giving hints for what I am personally looking for.)
I'm going to give one of the easy answers that probably a substantial amount of the respondents here can give: programming. Partly the point is to illustrate what sort of answer I am looking for.
One of the main tasks a programmer handles is fixing bugs. Often bugs are discovered because the user has encountered a situation where the program does something undesirable (for instance crashing or giving the wrong output). Usually this just annoys the user and nothing more happens, but sometimes the user reports the error and what they did before it happened to customer support, and then customer support enters it into a list of tasks that the programmers can look at.
The programmers may estimate the priority of various bugs that are reported. This priority can be estimated by various things, such as how commonly users report the bug (or statistically how common it is in logs emitted by the program), how severe it is described in affecting the usability of the software, and how much programmer time it is expected to take to solve it.
The bugs (and other tasks such as features) etc. are then assigned to programmers in the team based on things like familiarity with the parts of the software (often programmers mainly work with only one part of the programs they make), and the programmers work to fix them.
Typically the first step in fixing a bug is to reproduce it, so we know how to tell that it has been correctly fixed, and so we can inspect the program while it runs to figure out why the bug happens. The programmer may try to follow the steps that the user described in order to reproduce the bug, or they may use their knowledge of how the program works to infer different ways of reproducing the bug. If they cannot reproduce the bug, they may decide not to fix it, or send questions back to the customer to get more info on how to reproduce it.
In order to understand how the bug happens, they may read the code to see if they can deduce the rules that caused the bug. They may also run the program in a step-by-step manner, seeing how each variable affects each other. At times this can be difficult, for <complex reasons that I'd ideally explain but I'm on my phone right now so cutting it out for brevity>.
Once the bug has been understood, the programmer has to come up with a fix. Sometimes fixes a simple, e.g. changing the code to eliminate a silly programmer mistake. Other times the bug originates inevitably from other logic, and one has to break that other logic to fix it. The bug can also occur due to missing code, e.g. maybe only a special case was handled in the past, but now a more general case should be handled.
The fix must then be written into code, which involves a bunch of complex problem solving that I'm not even sure I know how to describe in non-technical terms. It's pretty important though so I should probably return to it after I'm off my phone. (Or if you feel like describing it, dear reader, I would encourage you to do so in a comment.)
Often programmers will also write a piece of code that can test the fix. This means that over time, the project can end up accumulating enormous numbers of automatic tests. And that's the next step: typically after a change is made, all the tests are run to ensure that nothing breaks.
Before the code is made a permanent part of the project, typically other programmers on the team will look at it and give comments on how to make it easier for them to understand, how to make it faster, and so on, such that the final code is reasonably good.
While doing all of these things, programmers typically have to manage a lot of technical things. For example, if the programmer is working on a web app, then the web app is typically run by multiple programs that work together. In order to run the app to e.g. reproduce a bug, the programmer may therefore need to configure the different pieces so they know how to find each other. Often configuration is partly handled by automatic tools, but these tools are often buggy and the programmer has to know how to navigate around those bugs.
This isn't a complete description of what programmers do, rather it is a description of one slice of programmer work (solving bugs).
I'm not sure I understand how this relates to your original question. Everyone's job exists at some level because they have a comparative advantage doing it, and specializing in it, compared to other people doing it for themselves. Even doctors have doctors and lawyers have lawyers.
I'm a consultant with a background in physics and materials science. Companies set themselves goals: growth, emissions reduction, and improving sustainability are the ones I focus on most. They work with my employer so a neutral third party can explain to them the landscap...
But of course people don't manually do this anymore, but instead use machines. And I've been told that they don't even manually drive the machines, but that they are instead automatically run.
I don't think either half of this sentence is true. A lot of crops are gathered by hand, either:
As for "machines drive themselves nowaday", even if by "people" you mean "US farmers", I don't think this is true. It is true that some such machines exist, especially for the farming of wheat and corn, but they aren't as widely used (yet) as you suggest.
As a side note, putting "of course" at the beginning of a statement doesn't make it true or stronger, although I don't believe in any ill intent on your part.
Because there is no technological alternative (e.g. strawberries, safran), or some quality standards require hand-picking (e.g. grapes)
Oops I specifically had wheat in mind when writing the stuff about farming. You are right that there's lots of stuff this doesn't hold form.
As for "machines drive themselves nowaday", even if by "people" you mean "US farmers", I don't think this is true. It is true that some such machines exist, especially for the farming of wheat and corn, but they aren't as widely used (yet) as you suggest.
I see, thanks.
This may sound like a question that is very big and impossible to properly answer in a LessWrong comment. And I think that's true. But still it seems like an important question to learn about, for many different purposes (I was thinking about this in the context of AI, but I assume it is also useful for other contexts, e.g. politics or entrepreneurship).
Abstractly the answer is something like "provide goods and services for people". But what concretely does this involve?
For instance one type of good that is provided is food, and a core piece of the manufactoring chain for food is farming. This is in principle like in children's stories. With farming, you have to put seeds (and fertilizer etc.) into soil, wait for a while (sometimes watering it, especially if you live in a dry region) for it to grow into edible plants, and then take those plants out of the soil again.
But of course people don't manually do this anymore, but instead use machines. And I've been told that they don't even manually drive the machines, but that they are instead automatically run. So I guess farming work really involves setting up and maintaining the machines? Which presumably involves all sorts of tasks related to the problems that can arise in the farming machines, which I don't know much about. So for example one valid answer to this question would be a description of some mechanical problems that can happen with farming machines and how those mechanical problems get fixed. Other valid answers for this part of the economy would include things about how the machines get produced, and how farmers sell the food they produce.
Speaking of selling, a huge part of the economy is coordination work. Sales, lawyers, managers, etc.. But even "coordination work" is fairly abstract. What exact tasks might it involve?
So yeah, I would be curious how much knowledge of what the economy is doing that we can collect.