SmartCoreAI are new Embarcadero components in Delphi 13, delivered as a separate installation. They implement some AI client-side ops, like chat, but stop short of tools calling / MCP.
Does anyone know if the next update may bring any more functionality there?
Alex.
The short answer is - yes - both in full product releases and āout of cycleā releases via GetIt as well.
TBH the GetIt package manager has dozens of AI related things from third parties, MVPs, and Tech Partners as well our own SmartCore. If anything, everyone is spoilt for choice! Every other new GetIt submission is from some new AI functionality or component.
We do intend to continue with AI components and functionality as well as improve and maintain other AI features like the integrated chat-style AI.
Watch CodeRage this week because there are several sessions which show all sorts of AI related topics including full āCopilotā type IDE integration, Vibe Coding (love it or hate it, it exists), and everything in between.
Thanks, Ian. But thereās no official roadmap ;-( Any way to find out which new features are coming approximately when? ā just sending a prompt to AI is the easiest, but would not really be in demand, because itās trivial. On the other hand, built-in infrastructure for 1) history, 2) tools and 3) context (RAG) would immediately make it usable.
Also, new MS SQL Server 2025 has new datatypes and syntax for AI/RAG. When would FireDac begin to support these natively? ā or is it already usable in Florence (actually, Iāll be trying it shortly anyway, but I honestly doubt it would allow an unfamiliar datatype)?
I bet both of the above requirements would be rather urgent for a lot of peopleā¦
Alex
I donāt have /any/ insider knowledge ā¦
but I do know that David Millington who is now with RemObjects, has been working on a āCoPilot for Delphiā type extension for the RadStudio IDE. (As an official RemObjects product)
I believe weāve been given some early glimpses quite some time ago ā¦ but his ambition for the project was /big/
And as far as I know, he will be presenting about it for CodeRage.
Idera donāt really do roadmaps, so itās not specific to SmartCore.
Iāve been logging lots of feature requests for SmartCore, and I would encourage you to do the same. Getting that common base in the box is a good start but hopefully the coming releases will see more attention on it.
Cheers
Malcolm,
Understood. Fair enough. But requests aside, if I want something now, Iām not waiting ā especially if there are no advertised timelines and the expected delay from a request to a solution can conceivably be years.
So Iāve defaulted to using plain TRESTClient. And would go deeper, down to THttpClient, if I come across any issues with TRESTClient.
There are many choices: these components, TMS components and a few more on GitHub, but even if any given set is but 1 feature short of the requirement, whatās the point of trying? And they all are. Quite understandably, but completely unacceptably. Any practical use case would involve a wide set of operations, so until itās all ready, they should not be advertising these components at all, IMHO.
To illustrate, these SmartCoreAI components are just half-baked shells, full of stubs like this:
function TAIOllamaDriver.ExecuteJSONRequest(
const AEndpoint: string; const AParams: string;
const ACallback: IAIJSONCallback): TGUID;
begin
DoError(Format(cAI_Msg_JSON_NotSupported, [DriverName]), EAIException, nil);
end;
So, whatever you touch, you get a āNot Supportedā exception back more likely than not. Pointless to start using them, itās a guaranteed dead-end. They should not be in the palette at all.
Alex
Thatās your call Alex, but weāve spent the last few years using RestClient (or our own wrapper) for various projects, and weāre already happily moving away from that to SmartCore for the current projects. No, it doesnāt do everything, but as youāve correctly pointed out, nothing does.
I donāt quite understand the view that it must do everything or else it is totally useless. Doesnāt that just mean you are left writing everything from scratch? Weāre using smartcore for what it does, and for the bits it doesnāt do, weāre using other things or rolling our own.
Cheers
Malcolm,
Trying to use, troubleshoot and extend someone elseās incomplete generic code may just be harder than writing everything up from scratch for a single specific case, I guess. Especially if the crux of the issue is some trivial JSON/REST comms. And with a chance that their initial design may not be able to be extended in some specific directions without a major rework.
And then every update to the base would break your additions. And so on, ad infinitum. Besides, you will not be able to answer any question about the framework, until you study it. So if you hit a bug, it would take you 10 times longer to find it, compared to one of your own. And with your own, you would already know all intricacies up-front, making it much more usable. Nah, itās just too laborious, unless itās perfect out of the box, or there are no other waysā¦
Alex
BTW, to send a simple prompt to an LLM is so trivial, you really do not need any special components.
Then there are tools/MCP and TMS have a good implementation, which would be hard to roll out on your own to the same standards.
But then it does not stop: there also needs to be some way to support conversation history and finally RAG. ā without tools, I would roll it out myself. But it looks like I would need to fall back to TMS components for tools, or it would take forever.
TMS is likely to be faster to add extensions and fulfill requests, so thatās my current bet, fingers crossed. And they already have some provisions for history/RAGā¦
Alex