If you're using the repository manager (and if you're not, you're in wild and unexplored territory) then there's an excellent chance you are in the wrong place in looking at the wftk core API, and you might just want to let the repository manager take care of workflow for you. But if you're pretty sure you want to talk to the core API yourself, that's what you'll find here.
This API is roughly object-oriented, making it relatively easy to embed in an object-oriented language. Notes on the class structure planned for the wftk are here. These classes are more or less language-agnostic, in that they will be substantially identical whether you're writing Python, Java, or C++.
In the wftk core, a process is represented by a datasheet. Internally, the datasheet is an XML document, which you manipulate using the XMLAPI library, a DOM-like set of functions which build and modify heap-based data structures based on XML (and which can be written to and read from actual XML files on disk or elsewhere.) I say, "internally," because you could easily write an adaptor which would talk to some other non-XML-based system to load a datasheet; that adaptor would build an XMLAPI structure which would be equivalent to the standard XML file used in the stock adaptor.
The datasheet contains values (hence its name), it maintains a queue of tasks and bookmarks into active workflows, it contains an enactment history of the process, and it will probably end up doing more as time goes on. In a very real sense, then, even though the users' activities focus on tasks more than on processes, your programming will focus on processes.
wftk_actionfunction. (You can grant or revoke full permission or cause the action to start an approval process; after approval, wftk will automatically complete the action.) WFTK -- it's not just for breakfast anymore.