Which "entity" is working at more deeper level than Characters of a program?
There are many pieces of software involved in rendering an "A" when you type it in to a program like a text editor.


First, the key press is handled by the hardware of the keyboard, which sends a signal to the OS's keyboard driver. This is where stuff like the
state of the shift key and caps lock get noted (though the
information about which modifier keys are pressed will usually just
be passed along with the information about the key pressed, rather
than "a" turning into "A" just yet).
The key press information next gets passed to the window manager
(which is usually part of the OS), to determine which program has
"keyboard focus" at the moment. If nothing has focus, the window
manager might discard the key press here (though it might also
intercept other presses, like ALT+Tab).
Next the active program likely gets a key-press event. Often the
program's event processing happens in a library provided by the
window system, though what it will do with the events after they
happen is up to the application itself.
An editor program will likely interpret a key press like "A" as input
for a file you have open. It will add the character to its memory
buffer representing the file's contents. This may be the first place
where the ASCII representation for "A" becomes relevant, as keyboards
and windowing systems often use their own codes for key presses. (Note though that a modern editor will probably use some encoding of Unicode, rather than ASCII to represent text. This adds some extra complication, but makes it possible to handle text in any language, not only English.)
Now the program has to draw the "A" to the screen. First it will
probably have to do a bunch of calculations to determine how it wants
to lay out all its text. Many editors wrap long lines of text, for
instance, which can be pretty complicated to get right.
Once the program has decided exactly where on the screen it wants to
put each part of its text, it will render them using a font. The font
describes what each glyph should look like (this is also very
complicated). The font render (which is often part of a library
provided by the OS or window manager, though an application can do
its own rendering if it really wants to) transforms the "A" to a
specific set of pixels.
Next, the pixels for the "A" (along with those for the other text,
and the rest of the editor's UI) get sent to the graphics driver.
Other programs may also be sending their own pixels if other windows
are visible alongside the editor. The window manager will usually
also have some parts of the screen that it manages itself (like the
taskbar, but sometimes also the borders of the windows).
The graphics driver sends on all the data to the hardware graphics
card in the machine. Some PCs these days (especially laptops) don't
have a dedicated graphics card, but they'll have a chip on the
motherboard that does essentially the same thing. The graphics card
will assemble all the graphics into a buffer representing all the
pixels of the screen. It will send the contents of that buffer to the
monitor every time it needs to redraw the screen (usually 60 times
per second, though other refresh rates are becoming more common).


The steps above are intended to be fairly general. Typing a key into a specific program on your computer may not have exactly the steps I describe (it could have more or fewer). For instance, if your editor is a console application rather than a graphical one, you may not have any window manager involved, and very basic fixed-width font rendering might be done directly by the hardware of the graphics card.

The exact boundaries between some of the layers may also be hard to distinguish in some cases, especially when the application is using libraries provided by the OS, window manager or graphics driver for some of the steps (like the event loop and font rendering).