I'd say that Service Fabric is a very flexible and powerful beast to cater many different needs, and you should definitely be able to build the desired architecture.
To create and control the flow, you could consider using SF Actors. You could easily build a pipeline or some sort of a chain where each Actor knows only how to complete its task, what next Actor to call upon the success and whom to complain if something has failed. To avoid having Actors doing long-running and intensive I/O work or something, you could leverage the reminders. For instance, as new portion of input arrives, call another SF service(an actual worker) where the console apps logic is implemented in to start the job, save the task id or any other attribute in actor's state to identify the 'worker', and set the reminder to check the status of the task in-progress. SF provides many different ways for its services to communicate with each other, so you could set up the interaction between Actors and 'workers' with a blink of an eye.
You could also play with GuestExecutables in SF if the console applications of yours have a huge non-trivial logic and you don't want to spend much time migrating the code in the beginning of your crusade.
It's just first thoughts and some very generic design. My point is, the SF is a very good choice when it comes to 'doing' services because of the variety of nice and robust options to handle many different cases.
P.S.
Check out Service Fabric Reliable Services Pipeline design. The discussion pertains to a similar topic and sheds a light on the details that you might find handy.
