FiveTech Support Forums

Dear Antonio,

thank you for your insights.

The more I work with these systems, the more I realize that my perspective may be different from that of a full-time framework or AI developer.

I am primarily an application developer. At the same time, I am involved in marketing, documentation, administration, customer support, web development and product management.

Because of that, my daily challenges are often not purely technical.

I need help with:

• software development
• web design
• SEO
• documentation
• support
• project organization
• business processes
• knowledge management

This is one reason why I am currently focusing more on the orchestration layer than on the execution layer.

Modern systems such as Codex, Claude Code and Gemini CLI already provide impressive execution capabilities. They can read and modify files, analyze repositories, execute commands, generate plans and automate many technical tasks.

My question therefore becomes:

Where should I invest my own development effort?

At the moment, I believe the greater value for a small company lies in organizing knowledge, workflows, project context, skills and working methods.

This is the direction in which the PE_EDITOR is evolving.

The goal is not to replace Codex, Claude Code or Gemini.

The goal is to make them easier and more useful to apply in everyday work.

Another important aspect is cost.

Whenever possible, I prefer solutions that work within existing subscriptions rather than requiring API usage for every interaction. Fixed monthly costs are easy to understand and easy to accept.

In contrast, variable per-request costs often create hesitation:

"Is this task worth spending credits on?"

That question alone reduces adoption inside a company.

The PE_EDITOR is therefore designed as a practical daily workbench.

It combines prompts, skills, project profiles, memory, knowledge bases and different AI providers in one place. It also acts as a learning system. When a new AI provider becomes relevant, it can simply be added and documented.

The new interface groups related AI systems together and provides information panels for each provider. The idea is not only to launch an AI, but also to help users understand its strengths, weaknesses, costs and typical use cases.

Perhaps my approach is less about building better agents and more about helping people work effectively with the growing number of agents that already exist.

I may be completely wrong, and this is exactly why I am trying to keep the discussion open.

I would be very interested in hearing where you believe this approach is weak and where a dedicated agent framework provides advantages that I may be overlooking.

Best regards,

Otto

Strategy for the Next Month

Expanding our AI workflow is not about automating everything as quickly as possible. Especially in mature projects, full automation is not automatically the better solution.

The more practical approach is: semi-automated instead of fully automated.

In the next phase, the PE_EDITOR should primarily be developed as a control center for AI-assisted work. It prepares the context, combines prompts, skills, project knowledge, variables, and memory, displays the final task instruction, and deliberately leaves the decision of which AI to use to the developer.

This is an important quality factor.

Because the best workflow is not:

Automatically send prompt
→ Accept response

but rather:

Prepare context
→ Review final prompt
→ Think critically
→ Choose the appropriate AI
→ Evaluate the response
→ Intentionally apply the result

An API middleware layer may become useful later, especially for repeatable tasks: comparing multiple AIs, automatically archiving responses, updating project documentation, or extending memory. However, for daily development work, the manual control point is not a disadvantage. It is a filter.

Therefore, the focus for the next month is on the following areas:

• Make skill documents easier to understand and more readable.
• Make project profiles easier to use.
• Improve the clarity and organization of memory.
• Enable manual saving of results and responses.
• Further structure and document AI providers.
• Evaluate API automation at a later stage.

The goal is not to remove the developer from the process. The goal is to prepare them better.

The PE_EDITOR should not automate blindly but instead structure high-quality AI work through context, control, and transparent decision-making.

Built a local AI Hub that lets me launch my favorite AI coding tools with one click.
No terminal commands to remember, no hunting for folders—just a clean desktop launcher for my development workflow.
Behind the scenes: exe-launcher.exe is a small Windows bridge built with Harbour.
It solves a common Windows issue where applications started by PHP/Apache may not appear in the user's visible desktop session, especially when Apache runs as a service.
The launcher monitors a local job file. When a tile is clicked in the web UI, PHP writes a launch request to that file. exe-launcher.exe detects the request, executes the corresponding launcher script, and then attempts to bring the new window to the foreground.
This ensures that Codex, Claude Code, Antigravity, VS Code, and other tools are started in the active user session instead of an invisible service session, effectively working around the Windows Session 0 Isolation problem.
In short, it's a lightweight Harbour-based bridge connecting a local PHP web menu with the visible Windows desktop, making AI coding tools feel like native desktop applications.

Xiaomi Mimo works incredibly well... :idea:

One thought that currently interests me a lot is the role of memory. Modern AI systems are increasingly building memory, projects, agents and complete ecosystems around their models. This is useful, but it also creates a dependency on a specific provider. My current idea with PE_EDITOR is therefore to keep: Skills Knowledge Bases Project Profiles Memory Decisions

inside the project itself and not inside a particular AI platform.

The AI provider then becomes an interchangeable execution engine. Today this may be ChatGPT, Codex, Claude Code or Gemini. Tomorrow it may be something else. Perhaps this is why I currently focus less on building my own execution agent and more on building a portable knowledge and workflow layer.

I may be completely wrong, so I would be very interested in hearing where you think this approach is weak and where a dedicated agent framework provides significant advantages.

Dear Otto,

We have to keep a GIT repo for each development.
The GIT repo is the "memory" where changes are tracked, turning it into the best "context" for the project.

Inside such GIT we should have:

1. readme.md (description of the project, overall explanation)
2. changelog.md (explanation for the most significant changes)
3. roadmap.md (guidelines for the development, where you go)
4. todo.md (pending things to implement, try, etc)
5. howto.md (specific rules to apply, used skills and tools -MCPs-)

You can use this repo from any Agent AI. It will provide the right conext to review and continue the development :idea:

Dear Antonio, yes, I understand the value of Git as project memory for source code. But in my case the word “project memory” is broader than source code history.

Our daily work does not only consist of source code projects. It also includes operational data, customer-related information, personal data, server configurations, documentation, support knowledge, marketing, SEO and business processes. Not all of this belongs into a Git repository.

This is why I am currently thinking in terms of a complete working environment on a dedicated server, accessed through RDP and protected by regular backups and server snapshots.

Git is excellent at remembering how source code changed. But PE_EDITOR is intended to help remember how the work around a project is organized:

what the project is about which rules apply which decisions were made which skills are useful which AI provider is suitable for which task what the current working context is

Another aspect is that many people in the FiveWin community are not traditional software developers working in large development teams. Many of us are application developers. We build tools for our own businesses, for customers, or for specific daily tasks.

In that environment, the challenge is often not only managing source code, but also managing knowledge, processes, documentation and practical experience accumulated over many years.

So perhaps Git and PE_EDITOR are simply different layers of memory.

Best regards, Otto

Dear Otto,

GIT is not just for source code. It is a knowledge database.

All that info that you mention, must be saved into a database. Different documents, rules, emails, etc. If you don't keep all the context into a database then the AI agent will not be able to access it and work with it.

If you keep your info into different places, its alright, but again it must be accessible by the Agent if you want the Agent to have a complete view. MCP for emails, spreadsheets, databases, etc. then it is required.

This is needed as LLMs are not able to manage users memory yet. I am possitively sure this will come also quite soon. Then there will be no need to save it ourselves.

Dear Antonio,

I think we fully agree on one important point: The knowledge must be accessible. An agent cannot work with information that it cannot see.

Where I currently think a little differently is in the areas of ownership, control and hosting. For our environment, it is important that: the data belongs to us the formats are defined by us the system remains independent of any particular vendor everything can be hosted on our own infrastructure GDPR requirements can be fulfilled

This is one reason why I currently prefer simple and transparent formats such as JSON for Skills, Knowledge Bases, Project Profiles and Memory. I also think our environments may be slightly different.

Our AI systems run on a dedicated development server behind VPN, together with the projects, documentation, tools and supporting systems. From our perspective, the challenge is therefore not primarily making the information accessible to OpenAI, Microsoft or another vendor.

The challenge is keeping the information accessible to ourselves while remaining independent of whichever AI systems happen to be popular in the future. Perhaps the real question is not where the memory is stored, but who owns it and who controls access to it. That is currently the part that interests me most.

Best regards,

Otto

The context from which I approach these topics:

I started as a one-person company and today work with a small team. WINHOTEL is a mature application that has evolved continuously over many years. I operate and maintain a self-hosted infrastructure on my own servers. GDPR compliance, data sovereignty, and long-term independence are non-negotiable requirements. Marketing, customer support, product development, and operations remain closely connected to day-to-day business realities.

A few lines to load a super fast Booking class as you can see from the video

It manages two modes:

Normal Hotel Management
and Morning and Afternoon (Half)

Seven type of Bars

1 = simple classic
2 = arrow hotel
3 = flat modern
4 = gradient modern
5 = shadow classic
6 = Austrian
7 = jet hotel

No Tplan, No Tgant but a new fast class

 oBooking:= TBookCtrl():New(,,oMain)
    oBooking:aRooms := aRooms
    oBooking:aReservations := CreateDemoReservations( aRooms )
    oBooking:bDelete := { |oCtrl,nRes| DeleteReservation( oBooking, nRes ) }
    oBooking:bStatus := { |oCtrl,nRes,nStatus| ChangeStatus( oBooking, nRes, nStatus ) }
    oBooking:bPrenota := { |oCtrl,nRes| ReservationDialog( oBooking, BOOKING_NEW, nRes ) }
    oBooking:bChange := { |oCtrl,nRes| ReservationDialog( oBooking, BOOKING_EDIT, nRes ) }
    oBooking:bToolTip := { |aRes| ;
   "Customer: " + aRes[6] + CRLF + ;
   "Check In: " + DToC(aRes[2]) + CRLF + ;
   "Check Out: " + DToC(aRes[3]) + CRLF + ;
   "Room: " + (aRes[1]) + CRLF + ;
   "Nights: " + ;
   AllTrim(Str(aRes[3]-aRes[2]+1)) }
   oBooking:bPopupMenu := { |oCtrl,nRes,nRow,nCol| MenuService( oCtrl, nRes, nRow, nCol ) }

Run also on resources

DEFINE DIALOG oDlg RESOURCE 1001

REDEFINE BOOKING oBook ;
      ID 100 ;
      OF oDlg ROOMS aRooms  HALFDAY
  AAdd( oBook:aReservations, ;
   { ;
      "0001", ;
      Date(), ;
      Date()+5, ;
      .T., ;
      .F., ;
      "Rossi", ;
      RGB(255,220,120), ;
      PLANNING_RESERVED ;
   } )