Without any precalculated tables, you can just build a standard chess playing engine (not specifically for endgames). Look, for example, here for a starting point. To optimize such an engine for endgames, you can try to automatically adapt your evaluation function whenever you identify a “known endgame” situation for which you have a specific evaluation strategy ready.

Pros: you will need typically much less storage than for a table-based solution. End game tables for 5,6 or 7 pieces will AFAIK need several Giga- or Terrabytes (rough guess of mine), for more pieces a table based approach won’t be feasible any more.

Cons: Your AI will be far from perfect (as opposed to an endgame table, which allows the engine to play perfect). End game situations suffer typically from the “horizon problem”. See this Wikipedia article about what was achieved over the last years by using table based retrograde analysis. You cannot expect to get such results from a standard engine.

Tableabase is not necessary for endgames.

Typically, this is done by designing two evaluation functions, one for middle game and one for endgame. For example, we’d prefer to move the king closer to the centre in the endgame.

Let’s take a look at the Stockfish code:

In https://github.com/official-stockfish/Stockfish/blob/master/src/evaluate.cpp

#define S(mg, eg) make_score(mg, eg)

Stockfish defines it’s scoring for both middle game and endgame.

Chess engine is fine for most endgames unless there are serious issues with search horizon.