When you talk about "generative" or "adaptive" plots, you run into a lot of problems with implementation.
The common approach is to carefully script out every possible plot. I call this the "big atom" method - the "atomic" elements of your plot are chunks of plot that are often several levels long. This produces a massive "branching" problem, where the more influence you allow a player, the more scripting you have to do. Lots of games use this method, including the much-vaunted KOTOR and Deus Ex series. And they have it polished: they know a lot of tricks to keep the branching down and reuse script.
But the fact is that the method is limited because you have to specifically script out every element of the plot.
An approach a lot of people try is a "small atom" approach, where they create tiny, generic plot elements that are stapled together over the course of the game. This isn't used in real games, however, because context is a huge part of games and we don't really have an algorithm for that figured out. At best, the "small atom" approach creates a meandering, disconnected plot. Normally, it creates gibberish.
There is really no "medium atom" approach in common use. The closest we have is map generators in things like Diablo, where individual chunks of a dungeon are created, but they are arranged into a map somewhat randomly. This works decently for hack-and-slash games, but if you try to implement it for a plot, you end up with the worst elements of big and small atom approaches: although any given segment of the plot makes sense, over the long haul the plot is a meandering mess. And you have to carefully script every element. Although rare, this method has been used occasionally, usually by people like Chris Crawford.
Sure, there are steps you can take to make these systems a bit more palatable. For example, you can use a "big atom" approach for the base plot, but then use "medium atom" elements to determine how the player guides the "big atom" elements. You can even subdivide that to allow the "medium atom" elements to be guided by "small atom" events... Siboot uses small atoms with medium atoms to give some context.
Alternately, you can be vague, generic, or carefully insert the reasoning between plot elements, allowing players to think there is some mysterious force behind things or letting them come up with their own reasoning. This works best in games where you can hear the player thinking and then come up with actual reasons similar to (but not exactly equal to) the player's reasoning. A computer game could be built with this in mind, but it has yet to be done.
However, these are all dodges. The real problem with all of these approaches is that a computer doesn't know anything about context, and programming it to know something about context is, as of yet, unproven theory. The larger atoms basically let the writers create more context, to supplant the computer's lack of context. Of course, what causes the branching and the pain is the fact that context changes as the plot progresses differently... so the writers have to write more variants, and you end up with a huge amount script.
As far as I can tell, there are three ways to implement context that aren't simply changing the size of the "atomic" script or pretending to have a magic algorithm that "knows" context.
1) Player-generated context. If you supply tiny story atoms to players, they will be happy to assemble them into fully functional plots that make sense. Assuming some kind of massive player base, you would see something akin to the Sims' photo albums.
2) Level-generated context. Similar to having AI navigate a level by embedding pathing and waypoints, you can have a "map" of a plot and fill it in with chunks that are context-suited. If you know that there is going to be a lovecraftian demon as your end boss, you can focus on adding horrifying plot elements rather than adventuresome plot elements, and even have a pseudorandom beginning, middle, and end. This is similar to having "intelligent" atoms, but far more centralized.
3) "Long atoms". If you want context, why not build the context into the atom? If you have a lovecraftian demon as an end boss, you can make that plot element "cast back" a series of hints and foreshadowing, even call for suitable atoms to attach to those nodes. Similarly, if you accomplish a subplot early on in the game, it can "cast forward" the repercussions, injecting elements into the play at later moments without needing to "connect" to whatever elements are currently active. This is basically the reverse of level-generated context.